19970821  057 


BIBLIOGRAPHIC  INFORMATION 


PB96- 148408 


Report  Nos:  STAN -CS -85 -1080.  KSL-85-12 
Title:  Compleat  Guide  to  MRS. 

Date:  Jun  85 


Authors:  S.  Russell. 

Performing  Organization:  Stanford  Univ..  CA.  Dept,  of  Computer  Science. 

Sponsoring  Organization:  *Office  of  Naval  Research,  Arlington.  VA. 

Contract  Nos:  ONR-N00014-81-K-0004 

NTIS  Field/Group  Codes:  62  (Computers.  Control  &  Information  Theory).  62B  (Computer 
Software) 

Price:  PC  A07/MF  A02 

Availability:  Available  from  the  National  Technical  Information  Service.  Springfield. 
VA.  22161 

Number  of  Pages:  129p 

Keywords :  *Logic  programming.  Artificial  intelligence.  LISP  programming  language.  Dat* 
bases.  Reasoning.  Knowledge  bases(Artificial  intelligence),  inference.  *MRS(Meta-leve 
Representation  System).  *Meta-level  Representation  System. 

Abstract:  Metal -level  Representation  System  (MRS)  is  a  logic  programming  system  with 
extensive  meta-level  facilities.  As  such  it  can  be  used  to  implement  virtually  all 
kinds  of  artificial  intelligence  (AI)  applications  in  a  wide  variety  of  architectures 
This  guide  is  intended  to  be  a  comprehensive  text  and  reference  for  MRS.  It  also 
attempts  to  explain  the  foundations  of  the  logic  programming  approach  from  the  ground 
up.  and  it  is  hoped  that  it  will  thus  provide  access,  even  for  the  uninitiated,  to  a1 
the  benefits  of  AI  methods.  The  only  prerequisites  for  understanding  MRS  are  a  passing 
acquaintance  with  LISP  and  an  open  mind.  The  first  part  of  the  book  deals  with  the 
principles  and  basic  commands  of  MRS,  and  is  sufficient  to  allow  the  reader  to  begin 
creating  fairly  complex  systems.  The  second  part  covers  the  advanced  features  of  MRS 
that  enable  the  user  to  tailor  the  system  to  her  own  needs  and  increase  performance 
functionality  as  desired. 


Jans  1535 


Report  No.  STAN-CS-SS-JCSO 
Also  numbered  K!iL-85-12 


PB96-149408 


The  Compleat  Guide  to  MRS 

by 

Stuart  Russell,  F.sq. 


Department  of  Computer  Science 

Stanford  Llnirersity 
Stanford,  CA  943QS 


PTIC  QUALITY  mSPECTED  3 


I 

I 


MMOOUCtOIT;  KIl^ 


Stanford  Systcsjj  Lefcorsfory 

Rsjscrt  No.  KSL-S5"12 


Stuart  Russell  Esq. 


COr^PUTER  SCIENCE  DEPARTMENT 

Stanford  University 
Stanford,  California  94305 


June  1935 


This  work  was  funded  from  ONR  contract  N00014>S1<K*0004 
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Preface 

MRS  u  &  logic  programmmg  fystcm  with  €xt«naiv«  meta-lcvel  facilities.  As  such  it  c^x  be  used 
to  implement  virtually  all  kinds  of  artificial  intelligence  applications  in  a  wide  variety  of  architectures. 
This  guide  is  intended  to  be  a  comprehensive  text  and  reference  for  MRS.  It  also  attempts  to  explain 
the  foundations  of  the  logic  programming  approach  from  the  ground  up,  and  it  is  hoped  that  it  will 
thus  provide  access,  even  for  the  uninitiated,  to  all  the  benefits  of  AI  methods.  The  only  prerequisites 
for  understanding  MRS  are  a  passing  acquaintancs  with  LISP  and  an  open  mind. 

Tht  first  part  of  the  book  deals  with  the  principles  and  bask  commands  of  MRS,  and  is  sufEcient 
to  allow  the  reader  to  begin  creating  fairly  complex  systems.  Ths  second  part  covers  the  advanced 
features  of  MRS  that  enabls  ths  user  to  tailor  the  sysUm  to  her  own  needs  and  increase  performance 
and  functionality  as  desired.  Ths  best  way  to  read  the  book  is  to  try  out  everything  on  the  terminal 
as  soon  as  it  is  introduced,  or  even  to  be  devtlopicg  an  application  concurrently  with  learning  the 
materiaL  There  are  several  exercises  provided  which  art  not  the  least  bit  optionaL  They  are  however 
non«trivial,  so  don’t  be  alarmed  if  some  of  them  seem  daunting*  In  the  author’s  opinion,  ths  style 
of  programming  induced  by  MRS  is  far  more  natural  and  uncomplicated  than  traditional  methods, 
and  it  is  only  the  corrupting  influence  of  previous  education  that  makes  logic  programming  seem  a 
little  strange  at  first. 

The  author  would  like  to  thank  Prof.  Michael  Genesereth  and  the  other  authors  of  MRS;  Russ 
Greiner,  Matt  Ginsberg,  Leonor  Abraido-Fandino,  Ben  Grosof  and  Renf  Bach  for  numerous  useful 
suggestions  and  diligent  reading;  and  Eric  Berglond  for  help  with  the  figures* 
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Chapter  1 

Introduction 

WLat  ifl  MRS?  Good  question.  MRS  etandt  for  Meta*level  Hepre^ntatioa  System.  If  your 
response  to  this  is  a  knowing  nod  of  understanding  yon  can  probably  skip  the  first  few  chapters. 
In  a  sense,  MRS  is  a  computer  language,  in  that  one  enters  text  in  a  designated  syntax  and  it 
gets  processed  and  produces  answers  (or  not).  But  because  MRS  is  also  able  to  reason  with  the 
information  you  give  it,  the  "program*  yon  ent^r  can  bo  seen  more  as  representing  facts  than 
specifying  a  process.  The  importance  and  utility  of  this  difTerence  will  become  clear. 

Jl.l  Problems  problems  problems 

Like  all  computer  languages,  MRS  is  a  tool  for  solving  problems.  By  the  time  you  have  mastered  it, 
you  will  know  how  to  use  it  to  solve  some  Very  Difficult  Problems  Indeed.  But  unlike  most  computer 
languages,  MRS  doesn’t  require  that  you  know  exactly  how  to  solve  a  problem  before  it  can  help 
you.  This  distinction  is  not  iron*dad  —  if  the  claims  of  AI  have  any  merit  then  Turin  g*equivalence 
assures  us  that  Albert  Einstein  could  be  implemented  in  BASIC  too  ~  but  the  normal  style  of 
problem-solving  in  MRS  is  radically  different  from  that  in  FORTRAN  or  even  LISP.  Yes,  even  today 
people  say  things  like  *The  great  thing  about  computers  is  that  they  make  sure  you  know  txacil^ 
how  to  solve  a  problem."  You  may  or  may  not  agree  that  this  is  a  great  thing,  but  with  the  advent 
of  MRS  (and,  I  suppose,  some  other  systems  too)  it’s  no  longer  true. 

The  (somewhat  idealised)  traditional  process  of  computer  use  goes  something  like  this: 

1.  Identify  the  problem. 

2.  Assemble  what  you  know  about  it. 

3.  Decide  on  data  structures  to  correspond  to  things  in  the  problem. 

4.  Figure  how  to  process  those  structures  to  produce  the  desired  answer. 

5.  Encode  the  process  step  by  step  in  your  favourite  language. 

3.  Get  the  computer  to  execute  the  process. 

wheress  the  happy  MRS  user  can  just  do  the  follov^g: 

1.  Identify  the  problem. 

2.  Assemble  what  you  know  about  it. 

S^  Encode  what  you  know  about  it  in  MRS. 

4'.  Get  MRS  to  figure  out  the  solution. 

That,  at  least,  is  the  plan.  The  key  problem  faced  by  the  experienced  programmer  coming  to 
MRS  is  that  she  can’t  stop  herself  from  doing  steps  1-4  from  the  old  tradition,  then  trying  $  in 
MRS,  whereupon  she  concludes  that  it’s  no  better  than  Pascal,  has  a  lot  of  silly  parentheses  and 
doesn’t  even  have  loops. 

The  new  regimen  places  more  emphasis  on  stage  2,  assembling  what  you  know  about  the 
problem,  which  is  often  overlooked  in  the  old  ways  with  diiastrcas  results  in  6.  It  should  already  be 
clear  that  less  effort  is  really  required  in  the  basic  procedure  for  solving  problems  in  MRS;  but  as 
any  Real  World  Programmer  will  tell  you,  that’s  not  the  whole  story.  Debugging  and  maintenance 
are  apparently  non-trivial  affairs.  Debugging  is  changed  as  follows:  clearly  if  all  you  have  is  facts, 
then  you  can  only  get  the  wrong  answers  if  some  of  the  facts  are  false.  Not  only  is  it  unlikely  that 
you  would  type  a  false  fact  in  the  first  place  (apart  from  typographical  inaccuracies),  but  it  is  also 
considerably  easier  to  notice  that  a  fact  is  false  than  it  b  to  decide  exactly  how  it  b  that  the  twelve- 
page  procedure  you  have  just  coded  doesn’t  correspond  to  the  solution  process  you  had  in  mind, 
even  if  the  solution  process  was  correct  in  the  first  place.  Maintenance  b  also  considerably  eased:  if 
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seme  facts  about  the  problem  cLanje,  the  enlightened  MRS  user  changes  the  corresponding  facts  in 
his  s>^«tem;  the  traditional  programmer  cusses  loudly,  tries  to  find  all  those  places  in  the  program 
where  the  solution  process  relied  on  the  truth  of  the  original  facts,  and  prays  that  the  changes  won't 
have  more  than  the  usual  number  of  side^efi^ects. 

Given  that  MRS  isn't  yet  Albert  Einstein,  this  has  been  an  idealised  version  of  the  truth,  but 
it  illustrates  the  basic  approach  that  should  be  followed  in  producing  applications  using  MRS. 

§1.2  Logic  doesn’t  rhyme  with  Magic 

You  may  suspect  that  the  stage  3'  above,  ‘Encode  these  facts  in  MRS*,  is  not  quite  as  straightforward 
as  all  that.  But  facts  are  being  encoded  all  the  time;  in  fact  you’re  i.iading  facUencodings  right  now 
(or  not,  depending  on  your  philosophical  inclinations).  To  see  that  a  fact  is  di^crent  from  a  sentence, 
recall  that  the  same  fact  could  be  expressed  ';7ith  difi'erent  sentences,  e.g. 

John  u  taller  than  Ken 

Ken  is  shorter  than  John 

or  even 

Ken  est  plus  petit  que  John. 

Some  of  the  linguistic  philosophers  m  the  audience  may  disagree  with  it,  but  this  simplistic  approach 
is  all  that’s  necessary  for  understanding  MRS. 

For  centuries,  philosophers  have  tried  to  devise  formal  languages  for  encoding  facts  about  the 
world  so  that  strict  rules  could  be  applied  for  deriving  new  facts  from  old.  In  this  way,  valid 
arguments  could  be  distinguished  from  invalid.  The  schemes  of  propositional  and  predicate  calculus, 
originating  in  the  work  of  FVege,  are  the  currently  accepted  standard.  The  important  thing  about 
these  schemes  is  not  the  particular  syntax  employed  or  the  applicable  rules  of  inference,  but  their 
way  of  viewing  the  world. 

According  to  predicate  calculus,  the  universe,  as  it’s  often  called,  consists  of  a  fixed  set  of  objects 
(not  necessarily  finite).  This  universe  is  not  usually  the  same  as  the  whole  Universe  As  We  Know 
It;  in  fact  it’s  often  a  very  small  subset,  for  instance  {John, Ken}.  A  key  notion  is  that  we  have 
independent  access  to  the  objects  —  we  know  what  we  mean  by  *  John’.  The  objects  need  not  be 
’real’  things:  unicorns,  numbers,  sets  and  Pepsis  can  inhabit  universes  too. 

In  the  formal  language,  we  will  have  constant  symbols  to  refer  to  these  objects  —  names,  if 
you  like.  For  example,  I  might  use  the  constant  symbols  John  and  Ken  or  jl2  and  k535  to  refer 
to  the  objects  John,  Ken  in  the  universe.  Notice  that  even  in  English  we  still  have  to  use  such 
symbols;  strictly  I  should  insert  the  real  John  and  Ken  mto  the  text,  but  even  modem  computerised 
typography  doesn’t  have  such  fonts.  The  point  is  that  the  idea  of  using  symbols  to  refer  to  actual 
objects  is  extremely  natural. 

In  English,  we  often  want  to  refer  to  objects  that  don’t  have  names  of  their  own,  such  as  John’s 
left  foot.  Similar  constructions  are  used  in  MRS,  and  are  called  terms.  Terms  are  written  with  a 
function  symbol  followed  by  its  arguments,  which  are  also  terms;  a  constant  symbol  is  a  kind  of  term. 
The  whole  lot  is  enclosed  in  parentheses.  So  we  might  write  (Lef tFootOf  John)  or  (LeftFootOf 
(FatherOf  Ken})  but  probably  not  (PootOf  Ken)  unless  we  were  in  a  world  of  molluscs:  a  term 
refers  to  a  unique  object.  It  is  essential  to  remember  that  terms  are  just  fancy  kinds  of  names;  they 
are  not  computable  expressions. 

Along  with  objects,  there  are  relations.  These  enable  you  to  say  things  about  the  objects,  and 
in  fact  that  is  basically  all  that  can  be  said*  In  my  universe  {John, Ken)  I  might  want  to  have  the 
relation  of  bemg  taller  than.  Now  whatever  I  might  think  about  the  meaning  of  such  a  relation, 
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accordiug  to  relational  eemanUci  a  relation  Le  deSned  bv  the  f«t  of  all  tuple*  of  object*  which  setLsfy 
the  relation  (it*  csienston).  Thu*,  iuppoee  my  relation  symbol  for  thi#  relation  it  liTtllerTbaa, 
Then  Ln  the  {John, Ken)  universe, 

I*TallerTh*a  H  {(John, Ken)}. 

Now  if  John  i*  also  older  than  Ken, 
leOlderThan  s  {(John, Ken)} 

•o  laTallerTbiiii  and  XsOldarThan  ax«  the  tame  relation.  Good  grief!  Actually,  thl*  itn’t  just 
plain  daft,  it’*  a  salutary  lesson  in  the  art  of  expressing  facts:  from  the  point  of  view  of  a  system 
•nch  as  MRS  containing  such  facts,  the  two  relations  axe  identical  since  one  could  exchange  the  two 
relation  symbols  througlout  and  not  affect  the  resxdt  of  any  computation.  In  fact  yon  could  replace 
IsTallerThan  by  G00062  and  stUl  not  change  anything.  The  system  rtally  dots  not  knovs  that  John 
it  (oiler  (Aon  Ken,  It  just  knows  that  laTallerThan  b  a  binary  relation  which  holds  between  John 
and  Ken.  For  many  purposes,  however,  it  b  useful  to  pretend  that  the  system  *knows^  these  facts, 
and  no  doubt  thb  grave  error  b  committed  liberally  throughout  thb  book. 

Notice  that  relations  come  in  many  different  kinds:  unary  relatiox^s  like 
PlayiBaeeball  s  {(John),  (ffen)}, 

binary  relations  like  IsTallerThan,  and  in  fact  relations  with  any  number  of  arguments. 

All  we  need  now  to  start  encoding  facts  in  our  formal  language  b  a  syntax  for  combining  relation 
symbob  with  constants  to  express  the  fact  that  the  relation  holds  for  the  objects  referred  to  by  the 
constant  symbob.  The  syntax  used  by  MRS  will  be  described  in  the  next  chapter,  along  with  more 
apparatus  of  predicate  calculus  that  enables  more  complex  facts  about  the  universe  to  be  expressed. 
Chapter  4  will  introduce  the  ideas  involved  in  inferring  new  facts  from  old.  These  ideas  are  the  k^y 
to  stage  4'  of  the  MRS  programming  process,  *Gct  MRS  to  figure  out  the  solution*. 
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Chapter  2 

Representing  knowledge  in  MRS 

The  preceding  chapter  introduced  the  idea  of  a  formal  language  for  expressing  facts,  but  didn’t 
actually  express  any.  The  reason  for  this  is  that  to  actually  express  a  fact  one  needs  to  choose 
a  syntax;  it  is  important  to  remember  that  tl.e  syntax  used  is  a  somewhat  arbitrary  choice  that 
must  be  clearly  distinguished  &om  the  ideas  of  representation  discussed  above.  The  choice  of  syntax 
depends  on  such  things  as  readability  and  ease  of  manipulation  by  computer  programs.  Because 
MRS  is  a  LISP-based  system,  the  syntax  is  chose  *  to  mesh  well  with  LISP.  The  following  sections 
discuss  the  actual  syntax  of  MRS. 

$2.1  Symbols 

Any  LISP  atom  can  be  used  for  constant,  function  or  re*  ;^tion  symbols,  with  a  few  exceptions: 

-  atoms  beginning  with  k  and  I  have  special  uses  which  will  be  explained  later; 
the  atoms  AND  OR  NOT  1?  should  not  be  used  as  relations. 

$2.2  Ground  literals 

Generally  speaking,  the  ejtpression  of  a  fact  in  a  formal  language  is  called  a  pnpontion.  The  facts 
^kat  we  didn’t  express  in  Chapter  1  are  called  ground  littrals  — ~  they  express  that  a  given  relation 
holds  between  the  given  objecU.  Given  the  above  hint  cbout  LISP,  you  can  probably  guess  that 
•John  is  taller  than  Ken*  is  expressed  by 

(IsTallerThan  John  Ken). 

Terms  with  function  symbols  such  as  (FathezOf  Ken)  can  appear  in  the  same  places  as  constants, 
so  since  John  is  Ken’s  father, 

(IsTallerThan  (FathezOf  Ken)  Ken) 

expresses  the  same  fact.  Since  terms  can  be  arbitrarily  nested,  we  could  say 

(PlaysBaseball  (FathezOf  (MotherOf  (FathezOf  Miranda)))). 

$2.3  Equality 

A  relation  with  a  special  meaning  in  MRS  is  the  equality  relation  *. 

(■  <tezml>  <tazB2>) 

is  true  if  and  only  if  the  two  terms  refer  to  the  same  object  in  the  universe.  Thus  (-  John  John) 
is  automatically  true;  (-  (FathezOf  Ken)  John)  is  true  as  long  as  John  is  Ken’s  father.  If  we  tell 
MRS  that 


(*  MozningStar  EvenlngStaz) 

then  there  will  be  two  constant  symbols  that  refer  to  the  same  object,  but  unless  otherwise  specified, 
MRS  will  assume  that  different  constante  refer  to  different  objects,  so  they  are  not  necessarily  -. 
Moreover,  MRS  is  equally  unable  to  decide  that  different  constants  neeessoriJy  refer  to  different 
objects,  so  they  are  not  necessarily  not  >  either. 

$2.4  More  complex  propositions 

Central  to  the  utility  of  predicate  calculus  is  the  idea  that  complex  facts  can  be  expressed  as  combi* 
nations  of  simpler  facts,  the  modes  of  combination  bemg  such  that  the  truth  of  a  complex  fact  can 
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be  deter  oned  from  the  truth  of  iti  coaatituenta.  Thus,  for  example,  the  fact  •John  is  taller  and 
older  than  Ken*  b  seen  as  a  conjunction  of  two  simpler  facts,  and  b  true  if  and  only  if  •John  b  taller 
than  Ken*  and  •John  b  older  than  Ken*  are  both  true.  Notice  that  the  same  property  docs  not 
hold  for  sentences  such  as  •John  b  taller  than  Ken  because  John  b  older  than  Ken*:  even  if  both 
parts  are  known  to  be  true,  say,  we  still  don’t  know  if  the  whole  sentence  b  true  or  fabe  because 
'because*  refers  to  a  context  of  causal  relations  outside  the  sentence  itself. 

Complex  facts  are  expressed  in  predicate  calculus  using  togicai  connectivu.  MRS  recognbes  the 
logical  connectives  AND,  OE,  NOT  and  IF: 

(AND  <propo8itioni  >  ...  <propo8itioan  >) 

b  true  when  all  the  conjoined  proposition!  are  true.  A  conjunction  of  no  proposition!  b 
true. 

(OR  <propo8itioni  >  •••  <proposltionn  >) 

b  true  when  any  of  whe  dbjoined  propositions  are  true.  A  dbjunction  of  no  propositions  b 
fabe. 

(NOT  <propo8ition>) 

means  that  the  proposition  b  fabe. 

(IF  <antecedeat  proposition^  <eon8«quent  propo8ition>) 

b  true  if  the  consequent  b  true  when  the  antecedent  b  true,  or  if  the  antecedent  b  false; 
Le.  the  consequent  follows  from  the  antecedent. 

§2.5  Variables 

Many  facts  that  we  might  want  to  express  are  general  in  the  sense  that  they  do  not  refer  to  any 
particular  object  or  objects  in  the  universe,  but  have  truth  conditions  depending  on  the  truth  of 
all  the  individual  propositions  generated  by  applying  the  statement  to  each  particular  object  in  the 
universe.  For  example,  in  the  {John,  Ken)  universe,  the  statement  •All  Americans  play  baseball* 
can  be  expressed  by 

(AND  (IF  (Anerican  John)  (PlaysBaseball  John}) 

(IF  (Aserican  Ken)  (PlaysBaseball  Ken))) 

and  it’s  truth  decided  by  using  the  mles  for  AND  and  IF.  But  for  larger  universes  thb  becomes  a 
tedious  way  to  express  what  seem  to  be  quite  simple  statements,  and  for  statements  like  •The  sum 
of  any  two  integers  b  an  integer*  the  task  of  enumerating  all  propositions  of  the  form 

(IF  (AND  (Integer  1)  (Integer  2)) 

(Integer  (♦  1  2))) 

b  really  quite  lengthy. 

Several  other  kinds  of  statement  are  commonly  used  which  have  similar  properties: 

•There  are  some  Americans  who  don’t  play  basebalL* 

•At  least  half  of  all  Americans  forget  to  vote.* 

•There  are  two  hundred  million  Americans.* 

MRS  provides  a  simple  mechanbm  for  expressing  only  univenal  propositions,  which  state  that  some 
fact  b  true  of  every  object  in  the  universe.  Of  those  mentioned,  these  are  1^  far  the  most  commonly 
needed  type.  All  you  do  b  use  a  special  symbol  type,  called  a  «aria6/e,  in  the  place  where  the 
cozistant  symbol  would  go  if  the  general  statement  were  applied  to  a  particular  object.  A  variable 
b  just  a  symbol  beginning  with  a  dollar  sign  I,  e.g.  |X  $$$  tvariabls.  So  the  statement  •All 
Americans  play  baseball*  b  expressed  as 

(IF  (American  $X)  (PlaysBaseball  $X}) 
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•Ever;  ^ King  ia  going  r/iong  ae  (literally  speaking) 

O.oingWrongr^  >y  $y) 

•Tho  sum  of  any  two  integ^i  u  an  integer*  as 

(I?  (AND  (intsstr  tX)  (Integer  tY)) 

(Integer  (♦  $X  $Y))) 

There  are  two  highly  important  thinp  to  note  abont  variables. 

Firstly,  the  particubjr  variable  name  yon  nse  is  irrelevant  (although  it  may  have  mnemonic 
valu.^).  Thus,  to  MRS,  (GoingVrongToday  $X)  and  (GolngWrongToday  Itverything)  are  the  same 
fact. 

Secondly,  where  variables  appear  in  more  than  one  place  in  a  proposition,  it  matters  whether 
they  are  the  same  or  different.  Thus 

(IF  (AND  (Integer  $X)  (Integer  IX)) 

(Integer  (♦  $X  $X))) 

means  something  very  different  from  the  proposition  above  that  also  uses  IT.  It  says  that  when  yon 
add  an  inti.;;er  to  iUtlf  yon  get  another  integer.  Thus  the  key  observation  is  that  whenever  a  variable 
occurs  more  than  once  in  a  proposition,  each  occurrence  will  refer  to  the  same  object. 

Unlike  many  systems  of  predicate  calculus,  computerised  or  not,  MRS  allows  variables  in  place 
of  fn^^/ons  and  relations.  At  first  this  may  seem  a  little  unnecessary  —  we  don’t  often  want  to  say 
things  like  (IX  Fred),  meaning  that  every  unary  relation  is  true  of  FVed.  But  in  restricted  universes 
where  we  are  dealing  with  a  known  set  of  relations,  this  might  be  useful  Also  we  can  use  this  facility 
to  describe  classes  of  relations: 

(IF  (Reflexive  |R)  (|R  |X  |X)) 

says  that  every  object  is  related  to  itself  by  any  reflexive  relation. 

§2.6  Existential  propositions 

In  the  previous  section  we  said  that  MRS  had  no  simple  way  to  handle  anything  other  than  universal 
propositions.  This  isn’t  quite  true.  Consider  the  case  of  exiiUnttal  propositions,  Le«  propositions 
which  state  that  some  fact  is  true  of  at  least  one  object  in  the  universe.  An  example  ia  given  above: 
•There  are  some  Americans  who  don’t  play  baseball*.  This  can  be  mterpreted  as  a  statement  about 
some  unknown  individual,  whose  sole  properties  are  that  she  is  American  and  doesn’t  play  baseball; 
we  can  invent  a  name  for  this  individual  such  as  LUH9781,  and  express  the  existential  proposition 

by 

(AND  (American  LUB978i)  (NOT  (PlaysBaeeball  LUB9781))) . 

It  is  essential  that  the  name  used  for  the  individual  be  new  in  the  sense  that  no  other  facts  in  the 
database  thus  far  can  have  mentioned  it.  Given  this  condition,  you  should  be  able  to  convince  yourself 
that  nothing  essential  is  lost  in  the  translation*  The  general  name  for  this  process  is  $koUmixationf 
but  the  general  process  for  arbitrarily  nested  universal  and  existential  propositions  is  too  complex 
to  be  given  here.  Any  good  textbook  on  predicate  calculus  should  contain  an  adequate  description. 

§2.7  Exercises  in  representation 

In  these  exercises,  the  given  symbols  have  the  obvious  meanings;  where  you  are  asked  to  write  your 
own  propositions,  use  an  equally  perspicuous  vocabulary. 

Express  the  following  propositions  in  reasonable  English: 
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1.  (Horse  Dobbin) 

2.  (Mssber  Dobbin  Horses) 

3.  (NOT  (Horse  Dobbin)) 

4.  (on  (Horse  Dobbin)  (Donkey  Dobbin)) 

5.  (I?  (Horse  Dobbin)  (Massnal  Dobbin)) 

6.  (I?  (Horse  $x)  (Hssnal  $x)) 

7.  (IF  (Oa  (Horse  $x)  (Cow  3x))  (FotJxL®sS«d  •x)) 

8.  (AND  (Msnnsl  $x)  (FourLegged  8x)) 

9.  (IF  (NOT  (Horse  Dobbin))  (Dutcbnen  Emintmde)) 

10.  (IF  (NOT  (Cow  $x))  (Brown  Dobbin)) 

IL  (IF  (AND  (Horse  U)  (NOT  (Htmaal  $x)))  (Cow  $x)) 

12.  (IF  (OR  (-  lx  Dobbin)  (•  |x  Tonto))  (Horse  lx)) 

13.  (IF  (AND  (-  lx  Dobbin)  (-  |x  Tonto))  (Horse  |x)) 

14.  (IF  (AND  (Mammal  |x)  (NOT  («  lx  Dobbin)))  (NOT  (Horse  |x)) 

15.  (IF  (AND  (Horse  |x)  (MOT  (-  lx  |y)))  (NOT  (Horse  |y)) 

16.  (NOT  (Member  lx  lx)) 

17.  (IF  (AND  (Horse  lx)  (Brown  |x))  (Brown  (TailOf  |x))) 
Express  the  following  English  in  reasonable  propositions: 

13.  All  dogs  bark  at  their  neighbours’  dogs. 

19.  No  real  numbers  are  integers. 

20.  Horses  who  hate  dogs  like  ice  cream. 

21.  Giraffes  have  longer  necks  than  Dobbin. 

22.  An- An  is  the  only  male  panda  in  London. 

23.  Zero  is  an  integer. 

24.  The  firactional  part  of  an  integer  is  sero. 

25.  The  product  of  two  real  numbers  is  a  real  number. 

26.  The  product  of  a  positive  integer  and  its  inverse  is  unity. 

27.  Zero  is  an  additive  identity,  (Don’t  say  (Additiveldentity  0) !) 

28.  The  product  of  two  real  numbers  is  never  an  imaginary  number. 

30.  All  numbers  are  either  real  or  imaginary  both. 

31.  AH  Englishmen,  Scotsmen  and  Welshmen  are  British. 
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Chapter  3 

Storing  and  retrieving  iacts  ~  the  database 

Once  all  these  facts  are  represented,  we  must  tell  them  to  MRS,  which  must  store  them  away 
somewhere  to  be  used  in  solving  problems.  Obviously,  we  should  like  to  be  able  to  inspect  and 
change  the  facts  at  wilL 

MRS  stores  facts  in  its  dataiate,  also  occasionally  known  as  the  knowledge  base  or  rule  base. 
Think  of  the  database  as  an  infinitely  extensible  repository  of  knowledge,  so  organised  that  the  time 
taken  to  retrieve  a  fact  from  it  is  essentially  independent  of  the  number  of  facts  it  contains.  But 
before  we  talk  about  the  MRS  commands  for  storing  and  retrieving  facts,  we  most  understand  the 
concept  of  a  query, 

{3.1  Queries 

b  MRS,  as  b  all  logic  programmbg,  problem  solutions  are  given  by  facts.  For  instance,  if  I  want 
to  sum  the  numbers  m  a  list  L  then  the  desired  solution  will  be  a  fact  of  the  form  'The  sum  of  the 
numbers  b  L  is  N” .  Database  retrieval  is  a  simple  form  of  problem>solvmg,  one  b  which  the  answer 
to  the  problem  is  a  fact  already  b  the  database. 

Suppose  we  have  a  very  simple  problem:  find  the  age  of  John.  Our  desired  solution  fact  will  look 
like  (Age  John  x)  for  some  x.  What  wo  need  to  do  is  ask  the  system  to  prove  a  fact  of  this  form, 
given  what  facts  we  have  already  put  bto  its  data  base,  b  MRS,  as  b  most  logic  programmbg 
systems,  we  can  pose  this  as  a  query  (Age  John  $x).  Note  that  this  isn’t  the  same  as  the  fact  b  the 
data  base,  which  would  mean  that  everythbg  b  the  universe  was  the  age  of  John.  It  is  askbg  the 
system  to  find  any  $x  such  that  lx  is  the  age  of  John.  The  query  is  b  fact  treated  as  an  existential 
proposition  to  be  verified.  (Note  that,  as  b  the  case  of  representbg  existential  propositions  b  the 
database  usbg  anonymous  constants,  we  can  have  universal  queries  too.  For  example,  if  we  wanted 
to  show  that  everyone  was  22,  we  could  use  the  query  (Age  G00089  22);  if  the  system  can  prove 
that  an  object  about  which  it  knows  nothbg  is  22,  it  can  prove  the  same  fact  about  anythbg.) 

Retumbg  to  our  simple  problem,  let’s  take  the  case  where  John’s  age  is  already  known:  (Age 
John  22)  is  already  in  the  data  base  (I  said  this  was  a  simple  problem).  The  system  succeeds  b 
solvbg  the  problem  by  notbg  that  (Age  John  22)  matches  the  query,  provided  we  let  lx  be  22. 
Such  an  association  of  a  variable  with  a  constant  symbol  is  called  a  Undinq.  b  MRS  a  bbdbg  is 
repented  by  a  CONSed  pair  such  as  (lx  .  22).  b  general,  a  query  could  have  more  than  one 
variable,  e.g.  (Parents  John  If  ether  Ifflothsr),  so  a  solution  is  represented  by  a  h'ndtng /ut  such 
as  ((Ifather  .  Ian)  (Inother  .  Iris)),  b  general  we  say  that  a  query  is  satisfied  by  a  bbdbg 
list  if  the  process  of  substitutbg  the  variable  bbdbgs  from  the  list  bto  the  query  produces  a  fact 
which  is  true. 

Suppose,  however,  that  we  know  that  everyone  b  our  universe  is  22,  Le.  (Age  |y  22)  is 
b  the  data  base,  but  John’s  age  is  not  specifically  mentioned  anywhere.  Obviously,  we  would 
like  the  system  to  produce  the  solution.  If  we  remember  that  (Age  |y  22),  as  a  dita  base  fact, 
it  shorthand  for  (Age  Alf  22)  (Age  Bert  22)  .  .  .  (Age  John  22)  .  .  .  (Age  Zack 

22),  then  the  answer  it  obvious:  allow  bbdbgs  for  variables  b  the  data  base  fact  as  well  as  b  the 
query.  Thus  b  this  case  a  bbdbg  list  ((lx  .  22)  (|y  .  John))  would,  if  substituted  bto  either 
of  the  two  propositions  (Age  |y  22)  and  (Age  John  |x),  produces  the  same  fact  (Age  John  22). 
The  substitution  bto  the  data  base  fact  produces  a  fact  which  is  still  true;  the  fact  thus  produced 
matches  with  the  query  fact  as  before,  so  the  solution  is  guaranteed  to  be  valid. 

The  process  of  findbg  a  bbdbg  list  which,  when  substituted  bto  two  propositions,  makes  them 
the  same,  is  called  unification.  The  bbdbg  list  is  called  a  unifier.  Thus  one  method  of  tiybg  to 
solve  a  problem  posed  as  a  query  proposition  Q  is  to  find  a  fact  P  b  the  data  base  such  that  that  P 
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4ad  Q  unify,  with  unifier  o.  If  we  denote  the  result  of  substituting  a  binding  list  #  into  a  proposition 
R  as  R^,  then  we  require  that  Pa  m  Q(7, 

$3.2  Exercises  on  umRcation 

For  each  of  the  following  pairs  of  propcaitions  you  are  to  find  the  binding  list  that  unifies  them 
(if  any).  Assume  that  variables  with  the  same  name  in  diferent  propositions  are  distbet,  eo  you 
will  have  to  rename  the  variables  in  the  second  propc^tlon  if  there  is  any  coafiict.  Some  of  the 
examples  contain  dot  notation  this  is  the  same  as  the  LISP  notation  for  CONS,  so  for  example 
the  propositions 

(p  $v  $x  (f  ly)) 

and 

(p  a  .  $z) 

unify  with  unifier  (($«  •  a)  ($n  •  ((x  (f  $y)))}. 

1,  (p  la)  and  ($r  z). 

2.  (p  la)  and  ($a  q). 

Z.  (p  la  c)  and  (p  ly). 

4.  (q  (f  |c))  and  (q  Id). 

5.  (r  (g  Ic))  and  (r  Ic). 

6.  (r  lx  (h  |x))  and  (r  |b  lb). 

7.  (p  la  (g  la)  (h  la))  and  (p  (g  lb)  (g  .  Ic)  (Id  .  |e)). 

8.  (q  la)  and  (|r  .  Is). 

9.  (r  lb  .  |b)  and  (r  |e  a). 

$3*3  Actually  doing  things  with  the  MRS  database 

After  such  a  lengthy  introduction,  even  the  most  diligent  reader  is  probably  itching  to  release 
the  awesome  power  of  MRS.  The  monitor^level  command  you  need  to  invoke  MRS  is  installation* 
dependent,  so  well  assume  here  that  MRS  b  ready  to  go. 

Commands  typed  to  MRS  are  actuaUy  typed  to  the  LISP  interpreter.  The  normal  LISP  read* 
evaLprint  loop  b  still  in  operation  All  MRS  commands  are  performed  by  functions  coded  in  LISP, 
so  the  ways  of  entering  commands  are  the  same  as  those  for  invoking  LISP  functions:  they  can  be 
entered  from  the  terminal  or  read  in  from  a  file  using  the  LOAD  function.  In  addition  the  KRSLOAD 
command  can  read  in  MRS  propositions  directly  from  a  file  (see  Ch.  10).  As  with  LISP,  text 
beginning  with  the  comment  character  *;*  b  ignored  op  to  the  end  of  the  line,  so  MRS  command 
files  can  be  commented  just  like  programs.  Ordinary  LISP  functions  can  be  invoked  at  all  times, 
and  MRS  functions  can  be  invoked  from  user  code. 

It  b  intended  that  the  reader  read  thb  chapter  sitting  at  a  terminal  and  type  the  entries  to 
the  right  of  the  >  symbol  Studies  have  shown  that  those  who  avoid  thb  become  stunted  MRS 
users*  Moreover,  the  facts  you  enter  here  will  also  be  used  in  chapter  4,  so  it’s  probably  best  to  work 
through  the  two  chapters  in  the  same  session. 

$3.4  Getting  facts  into  and  out  of  the  data  base 

The  straightforward  and  unromantically-named  STASH  command  does  the  straightforward  and 
unromantic  job  of  adding  a  new  fact  to  the  data  base.  Don’t  forget  to  quote  the  fact  you  are 
stashing. 

> (STASH  ’(Parent  Alice  Bert)) 
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P108 

> (STASH  '(Parent  Alf  Bert)) 

P109 

Yon  may  find  MRS'e  responses  a  little  pnzslisg,  not  to  eay  insnltbg.  What  it’s  actually  telling 
you  ia  that  your  propoeitione  have  been  stored  on  the  property  lists  of  the  atoms  P108  and  P109 
(the  actual  numbers  may  vary).  Theos  atoms  an  called  propc«Uioa  symbols. 

XSTASH  '(FsBals  Alice)) 

PllO 

>(STASB  '(Male  Alf)) 

Pill 

> (STASH  '(Mala  Bert)) 

P112 

An  alternative  to  STASH  is  ASSERT,  which  initially  does  exactly  the  same  thing.  However,  often  the 
user  will  want  further  inferences  to  be  made  automatically  from  the  facts  she  enten,  and  ASSERT 
ia  used  for  this,  whilst  STASH  is  normally  reserved  for  simple  storage  of  facts. 

To  retrieve  facts  from  the  data  base,  use  the  LOOKUP  command: 

> (LOOKUP  '(Male  Bert)) 

((T  .  T)) 

XLOOKUP  '(Penala  Alf)) 

MIL 

LOOKUP  returns  the  binding  list  that  satisfies  the  query.  If  the  query  contains  no  variables,  it  just 
nturns  a  nominal  list  ((T  .  T))  to  indicat'/  that  the  fact  was  in  the  data  base  —  this  distinguishes 
the  situation  from  that  pertaining  when  the  fact  can’t  be  found  and  LOOKUP  returns  NIL.  To  find 
out  the  name  of  Alf’s  child,  type 

XLOOKUP  ’(Parent  Alf  $x)) 

(($X  .  BERT)  (T  .  T)) 

As  you  can  see,  MRS  has  no  respect  for  '/our  careful  use  of  upper  and  lower  case,  but  don’t  abandon 
it  because  it  helps  to  make  your  source  files  much  more  readable.  You  may  find  that  variables  appear 
slightly  diflerently  ia  the  returned  binding  lists  —  this  is  a  LISP  effect  so  don’t  worry  about  it. 

Clearly,  some  queries  with  variables  can  be  satisfied  in  more  than  one  way,  such  as  (Parent  $p 
Bert).  LOOKUP  returns  the  first  solution  it  finds,  and  the  data  base  is  searched  ia  the  reverM 
order  from  that  in  which  the  facts  were  stashed.  This  search  order  is  an  important,  if  arbitrary,  part 
of  MRS.  It  can  be  used  to  give  a  kind  of  ’priority’  ranking  to  facU  and  rules,  and  is  important  u 
the  understanding  of  how  MRS  implements  various  defaulU. 

To  get  an  the  answers  to  a  query,  use  LOOKUPS  which  returns  a  list  of  binding  lists: 

> (LOOKUPS  ’(Parent  Ip  Bert)) 

(((IP  .  ALP)  (T  .  T))  ((IP  .  ALICE)  (T  .  T))) 

> (LOOKUPS  ’(Hale  |x)) 

(((IX  .  ALF)  (T  .  T))  ((IX  .  BERT)  (T  .  T))) 

> (LOOKUPS  ’(Parent  Ip  Ic)) 

(((IP  .  ALF)  (IC  .  BERT)  (T  .  T))  ((IP  .  ALICE)  (|C  .  BERT)  (T  .  T))) 

If  by  some  dreadful  mischance  yon  happen  to  stash  a  fact  that  isn’t  quite  true,  yon  can  remove 
it  using  UNSTASH: 
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>(miSTA5H  Alic*)) 

(FBfALE  ALICE) 

>(STASH  *(Godd«ffa  Alica)) 

Pli3 

Ab  extremely  oiefal  commuid  is  FACTS,  whidi  prints  mil  the  facts  contaimnf  its  argnunent 
(which  will  nsnally  be  an  atom,  but  can  be  a  term): 

> (FACTS  •Alice) 

P108:  (PARSKT  AUC2  BEST) 

Pii3:  (GODDESS  ALICE) 

FACTS  can  also  take  a  second,  numeric  aargument  indicating  the  maximum  lertl  at  which  the  first 
argument  may  appear  in  a  fact  for  it  to  be  printed  (rather  like  PRINTLEVEL  in  LISP).  See  chapter 
12  for  ways  to  specify  the  output  format  for  facts.  You  can  use  FACTS  to  avoid  the  tedious  chore 
of  typing  out  a  whole  fact,  character  by  character,  simply  in  order  to  unstash  it.  Calling  FACTS 
with  an  appropriate  argument  will  tell  you  the  proposition  symbol  for  the  unwanted  fact;  then  the 
system  function  Pattern,  which  takes  a  proposition  symbol  as  argument  and  returns  the  associated 
fact,  can  be  used  thus: 

(UHSTASH  (Patten  ’PliS)). 

UNASSERT  can  also  be  used  to  remove  facts.  Like  ASSERT,  it  is  normally  used  when  further 
inference  is  desired,  presumably  resulting  in  the  removal  of  dependent  facts. 
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Chapter  4 

Reasoning  with  Knowledge 
i4.1  Rules  of  Inference 

Having  entered  all  these  facts,  whai  mere  can  be  done  with  them?  How  does  MRS  fignre  out 
solutions  to  problems?  The  direct  answering  by  LOOKUP  of  queries  oa  the  database  can  be  seen 
as  a  simple  case  of  problem-solving,  and,  as  we  tsid  in  the  previous  chapter,  problem  solutions  art 
given  by  facts.  Thus  the  process  of  computation  in  MRS  is  one  of  producing  new  facts  from  the 
original  facte  encoded  about  the  problem.  Obviously,  we  canH  just  produce  any  old  facts:  they 
should  probably  follow  in  some  way  from  the  facts  already  known.  The  rules  which  determine  what 
facts  can  be  added  from  given  facts  are  called  rulti  of  infmKc*. 

A  rule  of  inference  is  usually  written  like  this: 

<  description  of  initially  known  fact(s)  > 

<  facts  that  can  be  inferred  > 

For  example,  if  we  know  that  (AND  A  B)  is  true,  we  can  infer  that  A  is  true  and  B  is  true: 

[AND  A  B)  [AND  A  B) 

A  B 

If  youVe  gone  to  a  lot  of  effort  to  make  sure  the  initial  facts  encoded  about  the  problem  are 
true,  then  usually  you*d  like  all  the  facts  inferred,  in  particular  the  solution  fact,  to  be  true  too.  An 
important  class  of  inference  rules  consist  of  those  which  guarantee  the  truth  of  the  inferred  facts 
provided  the  initial  facts  are  true.  A  S3rstem  using  just  rules  of  this  type  is  said  to  be  sound  and  is 
called  a  deductive  system.  A  system  with  a  set  of  inference  rules  which  is  sufficient  to  produce  all 
po$$ihU  deductions  from  a  given  set  of  facts  is  called  eompUte.  The  normal  inference  processes  used 
in  simple  MRS  applications  are  correct  but  not  complete. 

|4.2  Solving  more  difflcxilt  problems 

In  chapter  3  we  taw  how  to  solve  simple  problems  involving  database  retrieval  To  solve  problems 
whose  answers  we  don’t  already  know,  we  have  to  do  some  inference,  for  which  we  need  inference 
rules.  Where  do  we  get  those  from,  other  than  from  a  book?  Recall  that  our  logical  connectives  are 
defined  in  terms  of  the  truth  of  the  propositions  they  connect  —  hence  the  validity  of  the  inference 
rules  for  AND  given  earlier.  Rules  for  the  other  connectives  can  be  similarly  derived;  for  example 

A  [OR  A  B),  [NOT  A)  [OR  A  B),  [NOT  B) 

[ORAB)  B  - A - 

The  foUowing  is  the  basic  inference  rule,  called  Modus  Ponsns,  used  in  most  MRS  work: 

[IF  A  B),  A 
B 

which  basically  says  that  if  you  know  that  B  foUows  from  A,  and  you  know  A,  then  you  can  deduce 
B.  For  example,  if  we  know  (IF  (CurrentYear  1985)  (Age  John  22))  and  (CurrentYear  198S) 
then  we  can  conclude  (Age  John  22)  and  solve  our  problem.  The  reasons  for  using  this  inference 
rule  are 

1)  Most  of  our  knowledge  is  naturally  expressed  using  IP. 

2)  Even  if  it’s  not,  it  can  usually  be  rewritten  that  way. 
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The  truth  of  thc5«  two  itaitemsnU  will  become  apparent. 

Let  us  return  to  a  previous  example,  the  use  of  (Age  if  22).  The  diligent  reader  will  no  doubt 
have  spotted  that  this  is  really  a  dumb  thing  to  have  in  the  data  base.  For  instance,  it  implies  such 
things  as  (Age  22  22).  What  we  should  have  said  was  something  like  (IF  (Person  $y)  (Age  $y 
22}}.  Then,  given  (Person  John),  we  can  infer  (Age  John  22). 

Or  can  we?  As  it  stands,  no.  The  above  rule  of  inference  requires  that  the  exact  antecedent  A 
be  in  the  data  ba^e.  A  moment’s  thought,  which  you  should  think,  yields  the  extended  rule 


{IF  A  B), 


where  Aa  ■■  AV 


Le.  if  a  known  fact  %nifU$  with  the  antecedent  A  of  an  ZF-proposition,  then  we  can  infer  the 
consequent  B  modified  by  substitutions  from  the  unifier  a.  This  may  seem  highly  technical,  but 
really  it’s  just  a  formalisation  of  your  commonsense  btrition  of  how  such  ZF«propoeitions  should  be 
used. 

Typically,  an  IF^proposition,  henceforth  known  as  a  rule  (not  to  be  confused  with  an  inference 
rule),  hae  a  more  complex  antecedent  than  an  atomic  proposition  (i.e.,  a  proposition  with  no  con¬ 
nectives),  although  the  conclusion  will  usually  be  atomic.  To  avoid  havbg  to  have  a  whole,  complex 
fact  stored  m  the  database  to  unify  with  the  antecedent,  which  wouldn’t  be  usable  except  for  one 
particular  rule,  we  must  add  some  inference  rules  for  combbbg  atomic  propositions  bto  complex 
facts: 

A| ,  •  «  •  >  An 
(AND  Ax... An) 

for  t  1  •  • « IS. 

{OR  Ai...An) 

Given  these  inference  rules  and  database  such  as 


(IF  (Alio  (Happy  $x}  (KnovsRappy  $x}  (HaeHands  $x  |y)} 
(SbouldClip  $x  ly}) 

(Happy  John) 

(KnovsHappy  John) 

(HasHands  John  JohnsHands) 


we  can  deduce 


(ShouIdClap  John  JehneHands) . 


{4.3  Solving  really  very  difficult  problems  indeed 

To  get  all  this  to  hang  together,  we  need  a  method  for  performbg  multiple  inferences  and  stxingbg 
them  together  so  that  we  get  from  the  facte  at  hand  to  a  solution  to  the  user’s  query. 

Let’s  start  with  the  facts  at  hand.  Clearly,  one  way  of  gettbg  the  solution  it  to  find  a  rule  whose 
antecedent  is  satisfied,  apply  the  rule  of  inference  and  deduce  the  consequence.  We  could  then  add 
the  consequence  to  the  data  base  and  start  agam,  until  we  deduce  a  fact  that  unifies  with  the  query. 
This  is  called  forward  chaining^  for  obvious  reasons.  The  obvious  drawback  with  the  scheme  is  that 
the  system  could  end  up  makbg  dotens  of  inferences  that  bear  no  relation  to  the  task  of  provbg 
the  query. 

The  other  simple  alternative  is  to  start  with  the  query  and  ask  "How  can  we  prove  this?*  The 
answer  prove  the  antecedent  of  a  rule  whose  consequence  unifies  with  the  query.  That  is,  if  we  have 
to  prove  B,  and  there  is  a  rule  b  the  data  base  {IF  {AND  Aj  •  •  •  A^)  B’)  such  that  B’^  Bcr^  then 
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the  task  reduces  to  proving  Aia  for  all  i.  The  regression  ceases  when  we  find  an  antecedent  that’s 
already  in  the  data  base.  In  this  case,  we  only  examine  inferences  that  potentially  contribute  to  the 
actual  goal.  This  is  called  kicitsrard  chaining.  The  obvious  drawback  is  that  the  system  might  go 
off  trying  to  prove  antecedents  that  are  un provable,  or  even  false.  The  majority  of  expert  systems 
built  thus  far  are  basically  backward  chaining,  with  some  refinements.  The  "expert  knowledge* 
is  encoded  as  a  collection  of  rules  for  drawing  conclusions  under  certain  circumstances;  often,  the 
system  has  the  option  of  asking  the  user  to  confirm  an  antecedent  if  it’s  not  in  the  data  base  and 
can’t  be  proven. 

The  two  methods  are  illustrated  in  the  following  sections, 

$4.4  Using  inference  to  get  results 


Before  we  can  do  any  inference,  we’d  better  have  some  rules.  The  following  rules  define  some  family 
relationships  {we’ll  omit  MRS’s  responses  to  STASH  commands  from  now  on); 


>(STASH  ’(IP  (AND  (Parent  $p  tc)  (Ptmale  $p))  (Mother  $p  $c))) 
XSTASH  ’(IP  (AND  (Parent  Ip  $c)  (Male  $p))  (Pather  $p  $c))) 

> (STASH  ’(IP  (Parent  $p  $c)  (Child  te  Ip))} 

>(STASH  ’(IP  (AND  (Child  |e  Ip)  (Penale  |c))  (Daughter  |c  Ip))) 
XSTASH  ’(IP  (AND  (Child  |c  Ip)  (Child  Ip  |g))  (Grandchild  |c  |g))) 


Let’s  also  extend  our  family  by  giving  Bert  some  kids: 


> (STASH  ’(Parent  Bert  Cathy) 
> (STASH  ’(Peaale  Cathy}) 

> (STASH  ’(Parent  Bert  Chuck) 
> (STASH  ’(Male  Chuck)) 


The  normal  way  to  solve  problems  in  MRS  is  to  use  backward-chaining,  the  reason  being  that 
most  data  bases  are  more  amenable  to  this  approach;  we  will  see  later  that  the  MRS  user  in  fact 
has  a  good  deal  of  control  over  the  actual  strategy  to  be  adopted.  First  let’s  find  out  who  is  Bert’s 
daughter,  to  do  this  we  use  TRUEP,  which  is  like  LOOKUP  except  that  it  uses  backward  inference 
as  well  as  data  base  retrieval  to  find  the  answer 

> (LOOKUP  ’(Daughter  Id  Bert)) 

NIL 

> (TRUEP  ’(Daughter  Id  Bert)) 

((ID  .  CATHY)  (T  .  T)) 

It  is  important  to  understand  how  TRUEP  arrived  at  iU  answer.  The  first  step  in  any  attempt 
to  prove  a  goal  is  to  see  if  it  is  already  known  to  be  true.  Thus  TRUEP  calls  LOOKUPS,  which 
fails.  Then  TRUEP  looks  in  the  data  base  to  find  those  rules  whose  consequenU  unify  with  the  goaL 
Here  there  is  only  one  rule 

(IP  (AND  (Child  Ic  Ip)  (Pemale  le)}  (Daughter  |c  Ip}). 

After  applying  the  unifier  to  the  antecedent,  we  have  the  goal 
(AND  (Child  Ic  Bert)  (Pemale  Ic)). 

To  prove  a  conductive  goal  like  this  we  need  to  prove  all  the  conjuncts:  TRUEP  attempts  the  subgoals 
from  left  to  right,  but  this  is  an  arbitrary  choice  and  one  which  you  can  alter  when  you  know  how. 
To  prove  (Child  Ic  Bert),  since  LOOKUPS  fails,  we  must  use  the  rule 


/ 


TT - 
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(IF  (Pareut  $p  $c)  (Clilld  tc  Sp)) 
so  w«  must  then  prove 

(Paxant  Bert  $c} • 

LOOKUPS  succeeds  here,  returmns  to  TRUEP  %  binding  list 

((CJp  .  Chuck)  (T  .  T))  ((Jp  .  Cathy)  (T  .  T))). 

Thera  are  no  rules  for  concluding  parenthood,  so  that*s  all  the  solutions  there  are.  Having  got  these 
two  answers  to  (Child  |e  Bert),  we  must  tx7  to  prove  (Female  |c)  with  each  b  turn: 

(Female  Chuck) 

fails  because  it’s  not  m  the  data  base  and  there  are  no  rules  for  concludbg  such  a  propoeition  (at 
least  not  m  the  data  base). 

(Female  Cathy) 
succeeds  b  LOOKUPS,  so 

(AND  (Child  $c  Bert)  (Female  $c)) 
succeeds  with  $c  bound  to  Cathy  and  the  bbdbg  list 
(($D  .  CATHY)  (T  .  T)) 
is  returned  after  the  appropriate  subetitutions. 

NoU  that  if  LOOKUP  rather  than  LOOKUPS  had  been  used,  TRUEP  would  not  have  found 
the  answer  smee  only  (Parent  Bert  Chuck)  would  have  been  found.  Thus  even  though  TRUEP 
only  needs  to  return  one  solution,  all  alternatives  retrieved  must  be  considered.  Similarly,  b  proving 
a  goal,  we  must  not  ignore  any  poetible  solutions.  To  do  this,  believe  it  or  not,  TRUEP  actually 
calls  TRUEPS. 

Perform  a  similar  analysis  of  the  proof  procedure  for  the  followbg: 

> (TRUEPS  * (Grandchild  $c  Alice)) 

((($C  .  CHUCK)  ($1  .  BERT)  (T  .  T)) 

(($C  •  CATHY)  ($1  .  BEH)  (T  .  T))) 

>(TRUEPS  »($r  Alf  Bert)) 

((($R  .  PARENT)  (T  .  T))  <($R  .  FATHER)  (T  .  T))) 

Lookbg  at  the  returned  list  of  Alice’s  grandchildren,  you  may  be  wondering  what  $1  is  dobg  there. 
The  reason  is  that  sometimes  the  bbdbgs  of  t ntermeitate  varbbles,  Le*  variables  that  aren’t  b  the 
query  and  are  unbound  when  their  rules  are  bvoked,  are  Useful  b  understandbg  how  an  answer 
is  arrived  at.  Here,  $1  is  the  system-created  variable  that  replaces  Ip  (for  the  purposes  of  variable 
standardisation)  b  the  rule  definbg  the  Grandchild  relatbn.  Thus  it  informs  us  that  Bert  b  the 
parent  of  Alice’s  grandchildren  and  it  was  this  relationship  that  allowed  the  system  to  complete 
the  inference.  The  rest  of  the  guide  will  omit  these  bbdbgs  for  the  sake  of  clarity;  sometimes  the 
btermediate  variables  are  so  numerous  that  bbdbg  lists  become  almost  ’illegible’.  To  overcome 
this  you  can  process  them  usbg  getvar  and  related  functions  described  b  chapter  10. 

S4.5  Using  forward  chaining 

Forward  chabbg  b  MRS  is  not  quite  as  simple  as  backward  chainbg.  If  the  processes  were  entirely 
analogous,  we  would  give  the  system  a  query  then  have  it  reason  forward  from  all  the  facts  b  the 
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database  until  the  solution  wa.^  produced  or  until  no  more  inferences  could  be  made.  However,  this 
would  be  somewhat  incfBcient  since  most  of  the  inferences  would  probably  be  irrelevant.  In  fact, 
one  full  run  of  such  a  forward  chainer  would  produce  all  possible  solutions  for  all  possible  queries, 
and  can  easily  take  forever. 

The  method  we  adopt  is  to  assume  that  a  certain  small  set  of  facts  constitutes  a  description 
of  the  problem  situation.  These  facts,  together  with  the  background  knowledge  in  the  database, 
should  contain  the  seeds  of  the  solution  to  the  query  the  user  has  in  mind.  Thus,  when  the  user 
adds  the  problem  description  to  the  database,  the  system  forward-chains  from  thae  faeU  until  no 
more  inferences  can  be  made.  Then  the  user  need  only  do  a  LOOKUP  for  her  query  and  the 
answer  is  there. 

As  you  may  have  guessed,  the  user  must  add  the  facts  using  ASSERT.  But  first,  to  notify  MRS 
that  we  would  like  to  forward-chain  from  assertions,  enter 

> (STASH  ^(toassert  Ap  Ic)). 

Don’t  wony  yet  about  how  this  works.  Let  us  now  redo  the  example  of  the  previous  section. 
Assuming  the  rules  defining  family  relations  are  already  in  the  database,  we  will  assert  each  fact 
describing  our  particular  family  in  turn,  and  observe  the  actions  of  the  forward  chainer.  To  do  this, 
we  can  use  the  tracing  mechanism  of  MRS  to  see  each  step  of  the  inference  process  as  it  happens, 
by  entering 

e  >(TRACETASK  •Ax). 

Work  through  the  following  transcript  and  make  sure  you  see  how  each  conclusion  is  reached.  Each 
FCDISP  step  shows  a  fact  being  asserted.  After  it  is  in  the  database,  the  system  tries  to  find  all  those 
rules  which  have  a  premise,  or  a  conjunct  in  their  premise,  that  unifies  with  the  fact.  For  each  such 
rule,  it  then  performs  a  LOOKUP  on  each  of  tne  other  premise  conjuncts  (if  any),  and  if  successful 
calls  FCDISP  on  the  conclusion  of  the  rule. 

> (ASSERT  » (Parent  Alice  Bert)) 

Executing  FCDISP  on  (PARENT  ALICE  BERT) 

Executing  FCDISP  on  (CHILD  BERT  ALICE) 

DONE 

XASSERT  •(Parent  Alt  Bert)) 

Executing  FCDISP  on  (PARENT  ALF  BERT) 

Executing  FCDISP  on  (CHILD  BERT  ALF) 

DONE 

> (ASSERT  •(Female  Alice)) 

Executing  FCDISP  on  (FEMALE  ALICE) 

Executing  FCDISP  on  (MOTHER  ALICE  BERT) 

DONE 

>(ASSERT  •(Male  Alf)) 

Executing  FCDISP  on  (MALE  ALF) 

Executing  FCDISP  on  (FATHER  ALF  BERT) 

DONE 

> (ASSERT  ’(Male  Bert)) 

Executing  FCDISP  on  (MALE  BERT) 

DONE 

> (ASSERT  •(Parent  Bert  Cathy)) 

Executing  FCDISP  on  (PARENT  BERT  CATHY) 
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Ejteeutirg  FCDISP  oa  (CHILD  CATHY  BERT) 
Exeeu'.ing  TCDISP  oa  (GRAKDCHILO  CATHY  ALICE) 
Executing  FCDISP  on  (CRA,VDCHILD  CATHY  ALF) 
Executing  FCDISP  oa  (FATHER  BERT  CATHY) 

DOra 

> (ASSERT  ‘(Featl#  CetHy)) 

Executing  FCDISP  on  (FEKALS  CATHY) 

Executing  FCDISP  oa  (DAUGHTER  CATHY  BERT) 

DOfJE 

>(ASSFJIT  '(Percat  Bert  Chuck)} 

Executing  FCDISP  on  (PARENT  BERT  CHUCK) 


Executing  FCDISP  on  (CHILD  CHUCK  BERT) 

Executing  FCDISP  on  (GRANDCHILD  CHUCK  ALICE) 

Executing  FCDISP  on  (GRANDCHILD  CHUCK  ALF) 

Executing  FCDISP  on  (FATHER  BERT  CHUCK) 

DONE 

> (ASSERT  '(Melo  Chuck))  • 

Executing  FCDISP  on  (MALE  CHUCK) 

DONE 

>(UNTRACETASK) 

(AX) 

After  this  process,  the  qnery  (Deughter  $d  Bert)  already  has  its  solution  in  th<^  database,  so  a 
LOOKUP  is  sufficient  to  find  it. 

There  axe  some  restrictions  on  the  forward'chaining  routine  as  currently  implemented.  These 
mean  that  the  only  rules  triggered  when  a  fact  A  is  entered  will  be  those  of  the  form  (IF  A  E)  or 
(IF  (AND  . .  A  ■ .  )  B).  Thus  instances  of  the  proposition  embedded  in  disjunctions  or  any  other 
constructions  will  not  be  noticed. 

$4.6  Solving  problems  with  numbers 

MRS  knows  about  certain  relations  and  can  ascertain  the  truth  of  propositions  using  them  without 
recourse  to  the  data  base.  Arithmetic  relations  are  of  this  type: 

>(L00KUP  •(>  4  3)) 

((T  .  T)) 

MRS  knows  about  ><>■<■•♦-//.  The  latter  four  are  not  noplace  functions  (as  in  LISP)  but 
(n  +  l).place  relations;  for  example, 

(♦  $x  $y  lx) 

means  that  $z  is  the  sum  of  |x  and  |y. 

Thus  we  can  define  all  kinds  of  arithmetic  relations  (not  functions)  nsbg  these  as  primitives: 

>(STASH  ’(IF  (AND  (v  lx  ly  Isua)  (//  Isun  2  lavg)} 

(Average  |x  ly  lavg)) 

>(TRUEP  ’(Average  7  11  lx)) 

((IX  .  9)  (r  .  T)) 

Note  that  MRS  can  only  deal  with  these  relations  when  the  arguments  are  properly  bound: 
>(L00KUP  ’(>  lx  4)) 


c 
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HIL 

>a00KUP  •(♦  1  $x  3)) 

NIL 

A  nseful  way  to  view  arithmetic  and  other  ‘built-in’  relationa  is  as  virtual  faeU.  Apart  from 
the  restrictions  just  noted,  we  can  pretend  that  the  database  contains  an  infinite  supply  of  facts 
about  these  relations  (their  extensions,  as  defined  in  chapter  1).  Thus  there  are  virtual  facts  like  (> 
2  1)  ,  (♦  5  14  19)  and  (//  46  7  6)  ‘available’  to  LOOKUP.  The  concept  of  a  virtual  fact  can  be 
applied  to  any  built-in  relation,  and  several  more  such  relations  are  given  in  chapter  8. 

You  can  also  use  rules  with  TRUEP  to  define  recursive  relations.  Although  this  is  a  hoary 
example,  it  serves  to  illustrate  the  technique: 

> (STASH  ’(Factorial  0  1)) 

> (STASH  ’(IF  (AND  (>  $x  0) 

(-  tx  1  $x-l) 

(Factorial  8x-l  |factx-l) 

(•  lfactx-1  lx  Ifactx)) 

(Factorial  lx  Ifactx)) 

> (TRUEP  '(Factorial  6  In)) 

((IN  .  720)  (T  .  T)) 

Using  the  built-in  relations  can  be  quite  tedious  for  computing  a  complex  formula  since  each 
operator  m  the  formula  requires  a  new  conjunct  and  intermediate  variable  to  hold  the  result.  MRS 
uses  a  special  relation  IS  which  allows  an  entire  computation  to  be  done  in  one  step  with  a  functional 
representation  taken  dL  sctly  from  LISP: 

>(STASH  ’(IF  (IS  (-  (•  lb  lb)  (•  4  la  |c))  Id) 

(Discriainant  la  lb  |c  Id))) 

> (TRUEP  ’(Discriainant  2  4  1  Id)) 

((ID  .  8)  (T  .  T)) 

S4.7  Solving  problems  with  lists 

A  list  is  an  object  in  the  universe  just  like  any  other.  However,  unlike  numbers,  lists  have  no  ready¬ 
made  constant  symbols  which  MRS  recognises.  The  one  exception  is  the  empty  list  NIL.  Other  lisU 
are  represented  by  complex  terms.  Contrary  to  the  normal  syntax  for  terms,  MRS  has  a  special 
syntax  for  lists:  a  list  with  CAR  lx  and  CDR  |y  is  written  (lx  .  |y).  The  function  symbol  *.’ 
appears  in  the  infix  position  to  enhance  readability.  Other  than  this,  lists  are  treated  the  same  way 
as  any  other  terms  —  it  is  important  to  remember  that  is  not  a  LISP  function  which  is  executed, 
but  an  nninterpreted  symboL 

Let  us  define  the  APkilNO  relation  for  lists: 

(APPEND  NIL  II  ID 
(IF  (APPEND  111  113  ID 

(APPEND  (lx  .  Ill)  112  (lx  .  ID)) 

The  recursion  works  because  the  empty  list  NIL  can’t  be  unified  with  the  complex  term  (lx  .  11), 
so  TRUEP  continues  to  try  the  IF-rule  until  111  becomes  NIL.  This  may  seem  a  little  strange  at 
first,  especially  if  you  are  used  to  the  CAR  and  CDR  recursion  of  LISP.  Tty  doing 

(TRUEP  ’(APPEND  (1  .  (2  .  (3  .  NIL)))  (4  .  HIL)  ID) 
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for  yourself  on  paper  to  see  what  happens.  Then  just  to  make  sure,  and  to  get  another  insight  into 
why  writing  facta  is  better  than  writing  programs,  do 

(TRUE?  •(APPEND  (1  •  MIL)  $12  (1  .  (2  .  (3  .  MIL}}))) 


as  welL 

The  use  of  lists  in  MRS  is  far  less  common  than  in  LISP.  The  reason  for  this  u  that  facts 
usually  concern  relations  between  objects  rather  than  between  enumerated  collections  of  objects. 
However,  sometimes  you  wUl  want  to  know  properties  of  such  collections  which  can  only  be  obtained 
by  examining  their  contents;  for  example,  the  question  *How  many  grandchildren  does  Alice  have?* 
is  asking  for  the  cardinality  of  the  set  of  Alice’s  grandchildren.  MRS  provides  a  built*in  relation 
BAGOF  for  just  this  purpose. 

(BAGDP  $x  P  Is) . 

where  P  is  any  proposition  involving  $x,  means  that  la  is  the  bag  (or  ma/tuet)  containing  all  $x’s 
satisfying  P.  The  bag  itself,  to  which  $s  is  bound,  is  just  a  list  term,  as  in  LISP.  Since  bags  (and 
sets)  are  represent^  by  ordinary  lists  they  do  not  have  some  of  the  properties  of  sets  one  might 
expect  —  for  example,  two  sets  with  the  same  elements  are  not  necessarily  equal,  since  the  elements 
might  appear  in  different  orders. 

One  of  the  things  about  bags  is  that  elements  can  occur  more  than  once.  In  some  cases  these 
occurrences  will  be  ’spurious*  in  that  we  really  want  the  set  returned,  Le.  the  dutinct  solutions  for 
$x  of  P.  This  might  in  fact  occur  in  the  case  of  finding  the  number  of  Alice’s  grandchildren,  since 
there  could  be  multiple  ways  of  showing  that  someone  was  related  to  Alice  in  this  way.  For  these 
situations  MRS  provides  a  predicate  SETOF,  which  works  just  like  BAGOF  except  that  it  removes 
multiple  elements  before  returning  the  list.  As  a  result,  it  is  much  less  efficient  than  BAGOF  and 
should  only  be  used  when  necessary.  ^ 

Before  you  can  use  BAGOF  or  any  of  the  built-in  predicates  for  handling  sets  you  must  load 
the  file  SET  from  the  MRS  directory.  Do  it  now. 

OK,  now  that  MRS  is  apprised  of  sets,  let’s  try  it  out: 

r 

>(L00KUP  > (BAGOF  $x  (Malt  $x)  If)) 

((IP  ALF  BERT  CHUCK)  (T  .  T)) 

>(TRUEP  '(BAGOF  |x  (Gxaadelilld  |x  Alf)  |g)) 

(($G  CHUCK  CATHY)  (T  .  T)) 

Notice  that  the  binding  lista  for  If  and  |g  look  a  little  ,odd.  If  you  really  believed  the  atory  about 
what  MRS  lists  are,  yon  would  expect  (|G  .  (CHUCK  ,  (CATHY  .  NIL))).  But  in  fact  MRS  cheats 
a  little  and  uses  the  same  internal  representation  as  LISP  does  for  lists,  with  the  result  that  the 
LISP  output  routines  print  out  the  binding  as  a  normal  list  structure. 

To  find  out  the  number  of  Alice’s  grandchildren,  we  just  need  to  find  the  length  of  the  list 
representing  the  bag  of  them.  Thus  we  need  a  LENGTH  relation;  MRS  has  one  bnilUin,  and  this  is 
how  it’s  defined: 

(LENGTH  NIL  0) 

(IF  (AND  (LENGTH  II  In) 

(v  In  i  Inplttsl)) 

(LENGTH  (lx  .  ID  InplusD) 

but  the  welLknown  NoOfGrandChildren  relation  was  somehow  omitted  by  MRS’s  originators  so 
you’ll  have  to  put  it  in. 
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> (STASH  ’(IP  (AND  (BACOF  $x  (Grandchild  Sx  $7)  $g) 

(LENGTH  $5  $n)) 

(NoOf Grandchildren  %y  $n))) 

>(TRUEP  ’  (NoOf Grandchildren  All  $n)) 

(($H  .  2)  (T  .  T)) 

There  are  eeveral  other  bnilt-in  relatione  for  handling  Hate  and  sets  which  are  described  in 
chapter  8.  Using  these  relations  is  ranch  raore  efficient  than  writing  yonr  own,  since  they  nse 
compiled  LISP  code  rather  than  interpreted  MRS  facts. 

§4.8  Using  more  complex  rules 

So  far  aU  the  rules  we  have  encountered  have  had  a  premise  consisting  of  either  an  atomic  proposition 
or  a  conjunction  of  atomic  propositions.  What  of  the  remaining  connectives,  OB  and  NOT?  In  bach* 
ward  chaining,  when  a  goal  (NOT  <p>)  is  encountered,  the  only  way  of  proving  it  is  to  find  (NOT 
<p>)  in  the  database  or  to  find  a  rule  that  concludes  it  ^  in  other  words  negation  is  not  reducible 
in  the  same  way  as  conjunction.  On  the  other  hand,  disjunction  is  reducible,  since  a  disjunction  of 
propositions  is  true  if  any  of  the  {^positions  is  true.  So  aU  we  have  to  do  to  prove  a  disjunction  is 
to  try  proving  each  dbjunct  in  turn  until  we  find  one  that  is  true.  As  with  conjunctions,  this  is  done 
in  left*to>right  order.  If.  we  have  to  find  all  solutions  wo  try  all  disjnncts.  A  simple  example  is  the 
(AbsSlgn  $n  $b)  predicate,  which  returns  $s-0  for  $n-0  and  1  otherwise.  One’s  first,  LISP-based 
instinct  is  to  say 

(IF  (OB  (AND  (-  8n  0}  (-  $s  0)} 

>  (-  %•  D) 

(AbeSlgn  $n  $s)) 

which  unfortunately  doesn’t  do  the  right  thing  at  alL  The  ecror  shows  up  when  wo  call  TBUEFS 
on  AbsSign,  which  happensSrhen  we  try  to  prove  the  predicate  as  part  of  some  proof  in  which 
AbeSign  is  embedded.  Suppose  that,  when  we  get  as  far  as  AbeSign,  In  is  indeed  bound  to  0,  so 
that  AbsSign  succeeds  wjth  Is  bound  to  0,  but  then  a  later  part  of  the  proof  fails.  MRS  will  try 
to  find  the  alternative  solutions  to  earlier  parts  of  the  proof  to  see  if,  with  those  solutions,  the  later 
part  wiU  succeed.  Thus  it  wUl  try  the  other  disjunct  (-  Is  1)  and  succeed  with  that,  and  carry  on 
the  rest  of  the  proof  with  an  incorrect  binding  for  Is.  Clearly,  the  answer  iy  to  replace  that  disjunct 
with  (AND  (NOT  (-  In  0))  (-  Is  1)).  But  recall  that ‘(NOT  <p>)  can  only  be  proved  if  a  fact 
Ulls  ns  that  <p>  is  not  the  case.  It’s  hardly  likely  that  the  database  contains  facU  like  (NOT  (-  1 
0)),  (NOT  (-  2  0))  and  so  on.  So  we  are  in  a  quandary.  But  MRS  can  help  out  with  a  whole  new 
class  of  connectives  called  modal  operator*.  Whilst  a  whole  body  of  literature  has  been  written  on 
the  semantics  of  these  operators,  we  will  concentrate  just  on  what  they  mean  in  terms  of  the  proof 
process.  The  operators  that  MRS  provides  are  KNOWN,  UNKNOWN,  PROVABLE  and  UNPROVABLE.  Earh 
operates  on  a  single  proposition,  just  like  NOT,  and  meaiu  roughly  what  it  says: 

(KNOWN  <p>)  succeeds  if  <p>  can  be  satisfied  by  a  simple  LOOKUP. 

(UNKNOWN  <p>)  succeeds  if  <p>  cannot  be  satisfied  b^a  simple  LOOKUP. 

(PROVABLE  <p>)  succeeds  if  <p>  can  be  proved  from  the  facta  in  the  database,  so  it’s  a 

nuU  operator. 

(UNPROVABLE  <p>)  succeeds  if  <p>  cannot  be  proved  from  the  facts  in  the  database. 

In  this  case,  since  *  is  handled  using  LOOKUP,  we  should  say 
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(IP  (DR  (A>JD  (-  $a  0)  (-  U  0)) 

(AND  (UNKNO^H  («  (n  0))  (-  ts  1)} 

(AbsSign  $n  $s)) 

U!IKNO¥M  Mjxd  UliPROVABLS  are  extrememly  useful  in  all  kinds  of  fituationi.  In  any  instance  where 
something  that  isn^t  known  to  be  true  can  be  assumed  to  be  false,  we  can  use  these  operators  and 
avoid  the  chore  of  havbg  to  explicitly  stash  the  negated  propositions  which  the  use  of  NOT  would 
require.  This  assumption  is  called  the  c/osed-teor/d  ossurnphon,  and  is  used  all  the  time  by  us 
humans*  For  instance,  if  I  can’t  see  a  wall  in  ut  of  me  as  I  walk  down  a  conidorl  tend  to  assume 
there  isn’t  one  there.  In  a  logic  programming  environment,  we  have  to  make  these  assumptions  a 
little  more  explicit,  as  you  will  see  when  doing  the  exercises  in  the  next  chapter. 
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Chapter  5 

Some  (almost)  real  examples 

There  are  (at  least)  two  distinct  styles  of  usin^  MRS  corresponding  to  the  situations  in  which 
the  user  finds  herself:  she  may  already  know  how  to  solve  the  problem,  Le.  have  the  course  of 
the  necessary  computation  already  mapped  out;  or  she  may  not.  The  *code’  produced  in  the  two 
cases  is  not  necessarily  dissimilar,  in  fact  one  could  imagine  cases  where  the  same  programs  were 
produced  by  two  programmers  even  though  their  approaches  were  totally  different.  This  distinction 
is  reminiscent  of  that  between  AI  and  non-Al  programs. 

In  the  first  case,  where  the  user  knows  what  computation  is  needed,  facts  entered  as  rules  of 
the  form 

(IF  (AND  Ai...An)  B) 

are  understood  procedurally  to  mean  •To  prove  S,  prove  Ai  through  An  in  that  order*,  assuming 
backward-chaining  is  being  used.  The  user  thus  breaks  down  her  goals  into  subgoals,  often  using  the 
results  of  subgoal  Ai  in  tubgoal  until  trivial  subgoals  are  reached.  This  results  in  programs 
that  look  very  much  like  their  LISP  equivalents  (cf.  the  definitions  of  APPEND  and  Factorial); 
the  MRS  user  has  the  additional  advantages  of  the  implicit  computation  in  unification  and  the 
non-determinism  achieved  using  free  variables. 

In  the  second  case,  where  the  desired  computation  is  not  known,  MRS  (or  at  least  logic  pro¬ 
gramming)  really  comes  into  its  own.  In  the  following  example  we  wiU  produce  a  system  that  can 
predict  the  outputs  of  an  electronic  device,  consisting  of  wires  and  gates,  given  its  inputs.  The  stages 
in  the  general  method  are  as  follows: 

1)  Decide  on  an  ontology  for  the  domain  ^  the  contents  of  the  universe  and  their  categories. 

2)  Decide  on  a  vocabulary  of  relations  for  describing  both  the  problem  instances  and  the  general 

knowledge  used  in  solving  problems. 

3)  Collect  and  encode  all  the  general  knowledge. 

4)  Encode  the  description  of  the  particular  instance. 

5)  Invoke  the  appropriate  MRS  inference  procedure  to  produce  the  solution. 

Of  course,  the  first  three  stages  are  somewhat  interdependent:  the  ontology  may  depend  on 
the  knowledge  available;  a  new  problem  instance  may  tom  up  objects  not  yet  accounted  for,  and 
so  on.  For  example,  if  I  have  no  idea  how  temperature  affects  electronic  devices  I  won’t  want  to 
include  temperature  in  my  ontology  or  relations.  Similarly,  one  often  finds  the  need  to  rethink  one’s 
ontology  when  one  finds  that  the  knowledge  is  difficult  to  express  in  terms  of  the  current  set  of 
objects.  Thus  for  some  purposes  the  best  order  may  be  somewhat  different  from  that  given  above. 

Rather  than  just  dump  the  solution  on  you,  let’s  try  to  follow  the  stages  leading  to  it  in  detail 
and  motivate  the  decisions  leading  to  the  final  program. 

§5.1  Deciding  on  an  ontology 

This  is  not  the  same  as  having  a  clear  definition  of  the  problem.  A  clear  definition  of  this  problem 
class  is  that  it  consists  of  arbitrary  circuits  constructed  from  wires  and  two-input  AND,  OR  and 
XOR  gates  and  single-input  NOT  gates.  The  terminals  of  the  circuit  will  be  designated  as  mput  or 
output  terminals.  The  full-adder  circuit  in  Fig.  1  is  the  particular  example  that  we  will  consider. 
The  first  two  inputs  are  the  two  bits  to  be  added,  the  third  is  the  cany  bit  from  the  previous  addition. 
The  first  output  is  the  sum  bit,  the  second  the  carry  bit  to  be  included  in  the  next  addition. 

Presumably  we  will  want  to  include  the  gates  themselves  in  our  universe  since  we  have  to 
describe  their  behavior.  Similarly  the  full  adder  itself  has  terminals  and  a  behavior  (which  we  are 
trying  to  deduce)  so  we’ll  include  it  in  the  universe  and  call  it  F.  Since  we  won’t  want  to  describe 
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Figtire  1.  A  full  adder  circuit. 

the  behavior  of  each  individual  gate  when  we  need  only  describe  each  type,  we’ll  want  the  gate  types 
ANDGate,  ORGate,  XORGate.  What  else?  Wires?  Junctions?  Tenninals?  WeU,  the  terminals 
need  to  be  there  because  we  need  to  know  the  i/o  signals  at  them.  But  the  behavior  of  a  circuit  in 
this  idealisation  is  determined  by  the  components  and  their  interconnections  regardless  of  the  path 
or  type  of  those  interconnections,  so  the  junctions  and  wires  themselves  are  irrelevant.  Only  the  fact 
of  the  Literconnection  need  be  recorded.  Which  leads  naturally  to  the  next  stage. 

§5.2  Deciding  on  a  vocabulary 

First,  the  description  of  the  individual  gates: 

(Type  <gate>  <gate-type>)  e.g.  (Type  A1  ANDGate) 

Now,  the  behavior  of  the  devices  will  be  specified  in  terms  of  signals  on  their  tenninals 
(Signal  <terminal>  <value>) 
where  <Talue>  will  be  on  or  off.  We  could  equally  well  say 
(On  <terainal>)  and  (Off  <texBiaal>) 

but  reifying  the  signal  will  probably  allow  greater  flexibility  if  needed.  For  instance,  we’ll  need  to 
say  somewhere  that  the  signals  at  both  ends  of  a  wire  should  be  the  same;  then  we  can  say 

(IF  (AND  (Connected  $ti  |t2)  (Signal  $tl  $e}) 

(Signal  $t2  $e)) 

but  with  ON  and  OFF  predicates  we  would  have  to  say 

(IF  (AND  (Connected  $tl  $t2)  (On  $tl)) 

(On  $t2)) 

(IF  (AND  (Connected  $tt  $t2)  (Off  tti)} 

(Off  $t2)} 


Note  that 
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(IF  (AND  (Connected  $tl  $t2)  ($«  $tl)) 

($e  $t2)) 

is  no  good  because  it  would  imply  that  the  terminals  were  the  same  color  too* 

At  first  sight  one  might  think  that  the  terminals  can  be  named  just  like  the  gates:  Allnputl, 
Allnput2  etc.  But  the  rules  for  gate  behavior  need  to  Le  «/ritt«n  for  a  general  gate  not  just  a 
particular  individual,  so  we  need  a  function  symbol  which  will  refer  to  the  general  gate^s  terminals: 
(Inputl  Al)  perhaps;  if  we  follow  the  reification  principle  then  (Input  1  Al)  is  probably  better. 
So  to  state  that  the  second  input  of  gate  XI  was  on,  we  would  say 

(Signal  (Input  2  XI)  on) . 

The  interconnections  can  now  be  specified  easily;  for  example 
(Connected  (Output  1  XI)  (Input  1  X2)). 

{5*3  Collect  and  encode  all  the  general  knowledge 

The  problem  here  is  to  predict  the  behavior  of  a  device;  to  solve  it  we  need  to  know  how  the  signals 
are  propagated.  The  signals  are  propagated  through  wires  and  gates.  The  'wires*  are  easy  to  deal 
with,  as  shown  above: 

(IF  (AND  (Connected  $tl  $t2)  (Signal  $tl  $s)) 

(Signal  $t2  $•)) 

Of  course,  if  we  were  dealing  with  time-dependent  signals  and  finite-length  wires,  or  wires  with 
impedance,  then  the  system  would  need  a  lot  more  information. 

The  propagation  of  signals  through  a  gate  depends  on  the  gate  type.  The  following  facts  describe 
the  operation  of  the  three  types  of  gate  used. 

(IF  (AND  (Type  $g  ANDGate) 

(Signal  (Input  1  $g)  on) 

(Signal  (Input  2  )g)  on)) 

(Signal  (Output  1  $g)  on)) 

(IF  (AND  (Type  $g  ANDGate) 

(Signal  (Input  $n  tg)  off)) 

(Signal  (Output  1  $g)  off)) 

(IF  (AND  (Type  $g  ORGate) 

(Signal  (Input  1  $g)  off) 

(Signal  (Input  2  $g)  off)) 

(Signal  (Output  1  $g)  off)) 

(IF  (AND  (Type  $g  ORGate) 

(Signal  (Input  $n  $g)  on)) 

(Signal  (Output  i  $g)  on)) 

(IF  (AND  (Type  $g  XORGate) 

(Signal  (Input  1  $g)  $il) 

(Signal  (Input  2  $g)  $il)) 

(Signal  (Output  1  $g)  off)) 

(IF  (AND  (Type  $g  XORGate) 

(Signal  (Input  1  $g)  $ii) 
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(Signal  (Input  2  $g)  $12) 

(UNKNO^^II  ("  $il  $12))) 

(Signal  (Output  1  $g)  on)) 

§5.4  Encode  the  description  of  the  particular  instance 

In  tKij  c&ae  the  problem  motance  is  two-fold:  first  the  circuit,  then  the  particular  inputs.  The  circuit 
is  described  by  listing  the  types  of  the  gates  and  their  interconnections. 

(Type  Xi  XORGate) 

(Type  X2  XORGate) 

(Typo  A1  ANOGate) 

(Type  A1  ANOGate) 

(Type  01  QRGate) 

(Connected  (Input  1  P)  (Input  1  XI)) 

(Connected  (Input  i  ?)  (Input  i  Al)) 

(Connected  (Input  2  F)  (Input  2  XI)) 

(Connected  (Input  2  P)  (Input  2  A2)) 

(Connected  (Input  3  F)  (Input  2  X2)) 

(Connected  (Input  3  P)  (Input  1  A2)) 

(Connected  (Output  1  XI)  (Input  1  X2)) 

(Connected  (Output  1  Xi)  (Input  2  A2)) 

(Connected  (Output  1  A2)  (Input  1  01)) 

(Connected  (Output  1  Al)  (Input  2  01)) 

(Connected  (Output  1  X2)  (Output  IF)) 

(Connected  (Output  1  01)  (Output  2  P)) 

whilst  the  inputs  are  specified  by  giving  the  signal  value  at  each  of  the  input  terminals  of  the  adden 

(Signal  (Input  1  P)  on) 

(Signal  (Input  2  P)  off) 

(Signal  (Input  3  P)  on) 

§5.5  Invoke  the  appropriate  MRS  inference  procedure 

To  check  that  the  circuit  does  what  we  want,  we  need  to  check  both  outputs.  A  TRUEP  for  each 
would  suffice,  but  we  can  use  the  power  of  indeterminacy  to  get  MRS  to  go  through  all  the  outputs 
itself. 

>(TRU£PS  * (Signal  (Output  In  P)  $•)) 

(((IN  .  1)  (IS  .  OFF)  (T  .  T)) 

((IN  .  2)  (IS  .  ON)  (T  .  T))) 

which  is  the  correct  answer. 

You  may  say  ^That’s  all  very  well  for  those  mputs,  but  what  about  all  the  other  combinations?* 
It  would  certainly  take  a  lot  of  boring  typing  to  stash  and  then  unstash  all  eight  combinations  of  the 
three  mputs.  But  we  can  get  MRS  to  enumerate  them,  given  a  bit  of  thought.  To  find  the  possible 
inputs,  it  needs  to  know  the  possible  values  for  the  signal  on  a  terminal.  At  the  moment,  they  could 
be  on,  off,  green  or  angry  for  all  it  knows.  So 

(SignalValue  on) 
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(SignalValue  off) 

tell  it  what  it  needs  to  know.  Then  if  we  define  a  predicate  which  is  satisfied  by  any  combination 
of  inputs  with  their  respective  outputs  and  call  TRUEPS  on  it,  MRS  will  go  through  all  possible 
inputs  for  us. 

(IF  (AND  (SignalYalua  $11)  (Signal  (Input  1  F)  $11) 

(SlgnalValu#  $12)  (Slg;nal  (Input  2  F)  $12) 

(SlgnaXValua  $13)  (Signal  (Input  3  F)  $13) 

(Signal  (Output  $n  F)  $s)) 

(InputTested  $n  $11  $12  $13  $■)) 

> (TRUEPS  • (InputTeated  $n  $11  $12  $13  $a)) 

((($N  •  1)  ($11  .  OFF)  ($12  .  OFF)  ($13  .  OFF)  ($S  .  OFF)  (T  .  T))  ate. 

The  kind  of  reasoning  by  which  the  above  answers  are  produced  is  extremely  important  and 
foims  the  basis  of  all  scientific  thought  from  the  time  of  Newton  up  to  the  advent  of  quantum 
mechanics.  Basically  it  relies  on  the  notion  that,  given  a  description  of  the  initial  situation  and 
some  correct  laws  on  how  one  situation  follows  frx>m  a  preceding  one,  the  situation  at  any  future 
time  can  be  predicted.  The  knowledge  base  and  case  description  are  said  to  fonn  a  causal  model  of 
the  system;  such  models  are  increasingly  being  employed  in  expert  systems  that  deal  with  physical 
situations. 

You  may  have  a  nagging  intuition  that  it’s  an  odd  thing  to  do  to  work  back  from  the  outputs 
when  the  ‘flow  of  causality’  starU  from  the  mputs.  This  intuition  is  well-grounded  —  a  forward 
chaining  approach  would  be  more  efficient  smee  all  the  inferences  would  be  necessary  and  determined, 
whilst  the  backward  chainer  may  be  trying  to  prove  output  values  that  are  inconsistent  with  the 
inputs  before  it  makes  the  correct  choice.  A  highly  instructive  exercise  is  to  try  it  both  ways  with 
tracing  tamed  on. 
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§5*6  Exercises 

The  trouble  with  exercises  is  that  people  are  just  too  fat  and  laiy  to  do  them.  You  won’t  lose  weight 
by  doing  these,  in  fact  you  could  go  jogging  instead,  but  they  will  test  and  extend  your  ability  and 
understanding,  I  hope. 

1.  Writs  tome  rules  to  play  a  move  in  tictactoe.  The  board  representation  will  be 

(On  <player>  <square>) 

where  the  player  is  O  or  X  and  the  squares  are  numbered  left  to  right,  top  to  bottom.  To 

produce  a  move  the  user  should  be  able  to  type  simply 

>(TEU£P  ’(BeatMove  X  faove)) 

((/SHOVE  .  5)  (T  .  T)) 

Use  only  rudimentary  strategy:  take  a  win  if  available;  stop  an  opponent’s  win  if  necessary;  move 
at  random  otherwise. 

2. '  If  you  thought  that  was  a  little  too  easy,  now  do  the  same  for  a  chess  move.  Include  u  many 
details  of  castling,  pawn  promotion,  en  passant  moves  and  checking  as  possible.  To  make  things  a 
little  easier,  you  don’t  need  to  pick  the  best  move;  just  do  enough  so  that 

(TRUHPS  ’(LegalHovt  Vhita  liiove}) 

would  return  all  of  White’s  legal  moves.  You  will  have  to  decide  how  to  represent  the  board  and  the 
moves;  also  some  history  of  the  game  will  have  to  be  present  to  decide  on  castling  and  en  pasiant 
legality. 

Notice  that  by  writing  rules  that  decide  if  an  individual  move  is  legal  you  have  defined  the  space 
of  all  legal  moves  and  your  rules  can  be  used  as  a  generator  as  well  as  a  tester. 

3.  Create  a  knowledge  base  and  problem  description  sufficient  to  solve  the  geometrical  problem 
presented  in  Fig.  2. 

E 


D 


B 

Figure  2*  Glveu  <OAB  »  20*  find  <ECD 

T^  to  follow  the  stages  outlined  earlier  in  the  chapter  for  the  circuit  example.  A  hint  to  save 
you  some  head^scratching:  the  easiest  way  to  say  that  AB  is  a  tangent  to  the  circle  is  to  say  that 
AB  is  a  tangent  to  the  circle. 
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Chapter  6 

Controlling  deduction 

So  far  otir  description  of  MRS  has  concentrated  on  the  solving  of  problems  at  the  domain 
level  using  mainly  backward-chaining  inference.  In  this  capacity,  MRS  U  little  different  firom  other 
•yetema  aucli  as  PROLOG.  The  real  distinction  lies  in  MRS’s  ability  to  allow  the  user  to  express  all 
the  knowledge  the  has  about  the  best  way  to  go  about  finding  the  solution,  efficient  ways  of  doing 
particular  computations  or  the  overall  structure  of  the  computations  she  would  like  to  see  performed 
(the  arc Atiec tore).  Essentially,  at  each  stage  of  its  op^ation  MRS  uses  a  theorem-prover  to  find  out 
how  to  proceed;  by  making  facts  available  to  this  theorem-prover  the  user  can  tell  MRS  what  to  do 
and  how  and  when  to  do  it. 

§6.1  Tasks 

FVom  the  point  of  view  of  the  actions  that  are  being  performed,  computation  in  MRS  consists  of 
the  creation  and  execution  of  tasks*  Tasks  are  calls  to  LISP  subroutines  with  their  arguments;  they 
range  firom  calls  to  proof  routines  such  as  TRUHP  through  single  proof  steps  to  output  routine  calls. 
Executing  one  task  can  cause  other  tasks  to  be  created.  Given  a  method  for  making  tasks  available 
for  execution,  a  method  for  finding  out  how  to  perform  the  tasks  and  a  method  for  deciding  which 
of  several  tasks  to  execute,  we  have  a  general  architecture  for  computation  capable  of  producing  any 
desired  behavior. 

§6.2  Controlling  what  gets  done  when:  the  scheduler 

The  question  of  what  gets  done  requires  a  discussion  of  Ihe  mechanics  of  the  top  level  of  MRS  — 
the  scheduler  routine* 

0.2.1  The  general  (non*default)  mode  of  scheduler  operation 

The  scheduler  is  invoked  by  all  the  built-in  inference  routines.  In  its  most  general  mode  of 
operation  it  follows  the  deliberation-action  model  of  intelligent  systems  shown  in  Figure  4.  To  get 
the  scheduler  to  operate  in  this  mode  the  switches  executable  and  executed  must  be  set  to  T. 


Figure  4  The  deliberation-action  model 
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The  deliberation  part  is  aebieved  by  having  the  meta-lcvcl  thcorcm*prover  find  a  task  satiafying 
(executable  Jttesk).  There  are  of  coxirse  mcta-lcv«l  rules  to  decide  what  tasks  are  executable: 

(IF  (AND  (applicable  Atask) 

(IhTROVASLB  (disqualified  Atask))) 

(executable  Atask)) 

A  task  is  disqualified  if  another  applicable  task  is  preferred  to  it: 

(IF  (AND  (applicable  kanytask) 

(preferred  Itanytaek  ktaek)} 

(disqualified  ktask)) 

To  find  the  applicable  tasks,  we  first  find  the  runnable  tasks;  there  are  no  built-in  rules  for  deduebg 
runnability  so  this  is  where  the  user  can  decide  what  gets  done.  All  runnable  tasks  with  operators 
which  are  LISP  subroutines  are  automatically  applicable. 

Another  switch  preferred  determines  whether  tasks  can  be  disqualified  —  if  it  is  NIL  the  above 
rule  for  proving  disqualified  will  not  be  used,  whereas  if  it  is  non-HiL  the  rule  will  be  in  e^ci  t. 

A  simple  example  of  how  we  can. plug  into  the  deliberation  process  to  affect  what  gets  done 
is  the  implementation  of  demoru.  A  demon  is  a  task  that  is  to  be  executed  whenever  a  given  set 
of  conditions  becomes  true.  We  can  signal  that  a  task  should  be  executed  (or  at  least  scheduled 
for  execution)  by  asserting  that  it  is  runnable.  This  can  be  done  automatically  if  we  use  forward 
chaining  from  assertions  and  express  the  demon  as  a  rule  of  the  form 

(IF  <triggering  condition> 

(runnable  <task  to  be  executed>}). 

Usmg  this  mechanism,  the  range  of  system  architectures  that  can  be  implemented  is  enlarged  to 
include  blackboard  systems,  something  one  wouldn’t  expect  from  a  PROLOG  look-alike.  Essentially, 
these  demons  form  a  condition- action  architecture,  which  can  be  used  to  implement  any  desired 
structure  of  computation. 

0.2.3  Default  mode  —  the  agenda 

The  above  set  of  rules  is  only  used  in  full  when  the  switches  executable  and  executed  are 
non-nulL  The  normal  mode  of  operation  is  based  on  an  agenda.  The  variable  agenda  stores  a  list 
of  tasks,  all  of  which  are  automatically  applicable.  If  the  switch  preferred  is  NIL,  the  default, 
the  executable  task  is  the  first  one  on  the  agenda.  Thus  in  the  default  mode  the  agenda  is  empty 
until  a  top-level  command  is  entered  by  the  user.  The  LISP  function  (truep  or  whatever)  that  is 
invoked  places  itself  and  its  arguments  on  the  agenda  and  calls  scheduler,  thus  connecting  with  the 
scheme  described  above.  All  the  built-in  inference  routines  use  the  agenda;  the  normal  base-level 
backward-chainer  be  puts  bedisp  tasks  on  the  agenda;  f  c  puts  f  edisp  tasks  on  the  agenda,  and  so 
on. 

When  the  preferred  flag  is  non-null,  the  tasks  on  the  agenda  are  compared  to  find  the  most 
preferable  one,  thus  disqualifying  all  the  others,  at  least  in  theory.  In  practice,  for  efficiency  reasons, 
the  executable-related  rules  are  skipped,  and  the  preferred  task  is  executed  immediately. 

{6.3  Telling  MRS  how  to  do  things 

This  section  introduces  the  ideas  involved  in  specifying  how  MRS  is  to  execute  the  tasks  it  encounters. 
The  range  of  tasks  which  can  be  handled  is  given  in  the  section  on  task-related  attachment  in  chapter 
8;  here  we  present  tome  motivation  and  a  detailed  example  of  the  kind  of  information  the  user  can 
give  the  system  for  deciding  how  to  perform  tasks. 
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We  have  already  eeen  tome  ttraitge  n?t?mbliiig  necesaary  for  doing  forward  chaining.  The  exact 
incantation  waj 

(STASH  ’(toassert  kp  fc)). 

Its  effect  was  that  all  subsequent  assertions  caused  fonvard-chaining  to  t^ils  place.  Instead  of  using 
the  normal  LISP  subroutine  for  assertions  {whicb  is  the  same  as  that  for  STASH  bitially),  MRS 
will  call  ic  with  the  asserted  proposition  as  argument.  Wb^never  a  task  such  as  an  ASSERT  or 
TRUEP  is  scheduled  to  be  executed,  MRS  looks  up  the  appropriate  subroutine  to  me  under  tosssert 
or  totruep.  Thus  by  stashing  facU  like  (tci^ssert  Ax  f  c)  we  can  affect  the  way  in  which  MRS 
performs  the  commands  we  give  it.  Ssch  facts  are  qualitatively  different  from  the  domain  facts  since 
they  deal  with  how  those  are  to  be  used  rather  than  stating  truths  about  objects  in  the  universe; 
they  refer  to  the  sinding  status  of  variebles,  the  order  of  processing  of  conjuncts,  the  method  of 
representation  for  fact  classes  rather  than  Zen  or  automotive  diagnosis  and  repair.  Thus  they  encode 
meta-knowUdge  (meaning  ‘knowledge  about  knowledge*)  and  are  said  to  be  at  the  meta-Uvei  It  is 
MRS’s  extensive  facilities  for  representing  and  ming  this  kind  of  information  that  give  it  the  name 
‘Meta-level  Representation  System*.  We  will  see  many  more  examples  of  meta-level  knowledge,  but 
first  we  need  some  background  to  show  why  it’s  necessary. 

We  have  already  seen,  in  the  case  of  predicting  the  outputs  of  electronic  devices,  that  forward* 
chaining  can  be  more  efficient  than  backward  chaining.  This  piece  of  meta-level  information  was 
put  into  action  by  asserting  the  input  values  rather  than  stashing  them  and  by  telling  MRS  to 
forward-chain  from  assertions.  When  is  this  a  good  idea  in  general?  To  discuss  this,  we  need  to 
think  about  the  structure  of  the  rule  base.  Suppose  that,  for  any  given  conclusion  (such  as  the  value 
of  an  output),  there  a  doien  different  rules  for  deducing  it.  Then  a  backwardndiaiaing  system  has 
to  try  all  of  these  even  if  only  one  of  them  leads  to  a  solution.  Then  again,  if  a  given  fact  (say  the 
value  of  an  bput)  is  used  m  the  premises  of  a  dosen  different  rules,  then  a  forward-chabbg  system 
might  trigger  ^  of  these  rules  when  only  one  of  them  leads  to  the  desired  answer.  Fig.  3  illustrates 
the  difiTerence  b  the  two  types  of  rule  base  b  diagrams  showbg  rules  as  nodes,  with  an  arc  showbg 
that  the  conclusion  of  the  rule  at  the  left  end  unifies  with  part  of  the  premise  of  the  rule  at  the  right 
end. 


Figure  3 


Good  for  forward  ehabbg 


Good  for  backward  ehabbg 
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Applying  this  simple  analysis  to  the  family  relations  example  in  section  4.2,  we  tee  that  the  only 
chaining  occurs  on  the  Child  relation;  it  appears  in  one  conclusion  but  three  premises,  therefore  the 
database  structure  is  best  suited  for  back  ward-chaining. 

Certainly  it^s  true  that  in  many  real  cases  the  choice  is  not  so  simple,  for  example  when  the 
database  diagram  contains  loops.  But  we  shall  now  try  to  get  MRS  to  do  this  kind  of  analysis 
automatically.  Being  a  meta>level  system,  MRS  can  reason  about  how  to  do  things  using  facts 
which  the  a^er  can  provide,  thereby  directly  bSuencing  the  operation  of  the  system.  Specifically,  it 
uses  a  backward-chaining  theorem-prover  and  mcta-level  facta  to  solve  meta^level  problems.  When 
given  a  command  such  (ASSERT  <p>)  MRS  calls  a  stripped-down  version  of  TRUE?  called  trtruep 
on  the  goal  (toassert  <p>  kaethod).  trtruep  is  stripped-down  m  the  sense  that  it  doesn’t  have 
access  to  any  ineta-meta*level,  so  it  runs  pnre  backward-chainmg.  Thus  all  that’s  necessary  is  to 
stash  a  fact  of  the  form 

(IF  <database  suitable  for  forvard*-chainixxg> 

(toassert  kx  fc)). 

Notice  that,  at  the  meta-level,  variables  begin  with  k  instead  of  $.  The  meta-level  theorem-prover 
treats  all  base-level  variables  as  constants;  the  base-level  theorem  prover  treats  metvlevel  variables 
as  constants.  This  is  actually  done  by  havbg  two  different  unification  routines,  one  for  each  level. 

Often,  users  who  are  happy  with  base-level  programming  are  wary  of  working  at  the  meta-level, 
perhaps  equating  it  with  ’system  hacking’.  Nothing  could  be  further  from  the  truth:  the  meta-level 
is  for  expressing  and  using  abstract,  high-level  knowledge  about  how  problems  should  be  solved.  So 
to  overcome  your  trepidation  or  distaste,  we’re  going  to  plunge  in  and  do  an  example  that’s  probably 
more  complex  than  anything  you’ll  ever  want  to  do  at  the  msta-leveL  We  shall  implement  a  simple 
definition  of  the  predicate 

•'database  suitable  for  forvard  chaining> 

which  will  involve  some  quite  tricky  problems. 

Interpreting  simplistically  the  above  analysis,  we’ll  say  that  a  database  is  suitable  for  forward 
chaining  if 

the  average  number  of  premises  unifiable  with  each  conclusion 
is  less  than 

the  average  number  of  conclusions  unifiable  with  each  premise. 

This  approximately  corresponds  to  the  rorward-search  branching  factor  being  smaller  than  that  for 
backward  search. 

To  convert  this  into  an  MRS  predicate,  the  top-down  approach  will  be  used.  The  basic  condition 

is 

(IF  (FC^Indieated)  (toassert  kp  fc)). 

Note  that  FC*Indlcated  has  no  arguments:  it  is  a  condition  on  the  whole  database  available  at 
the  time  we  make  the  assertion  that  causes  MRS  to  try  to  find  out  how  toassert.  iVom  the  above 
definition  we  have 

(IF  (AliD  (ForvardBrtnch  kffactor) 

(BackwardBranch  kbfactor) 

(<  kffactor  kbfactor)} 

(FC*Indicated)) 

We  will  define  just  the  forward  branching  factor  here  and  leave  the  rest  to  the  reader’s  fertile 
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imaguiatlon. 

(IF  {AND  (BAGOF  to 

(AND  (IF  ^rea  Aconcl) 

(NoOfMatchingPxeaises  Aconcl  An)) 

Aaatclmujnbers) 

(Average  Aaatchnuabers  Af factor)) 

(ForvardBranch  Af factor)) 

To  understand  this,  recall  that  (BAGOF  <X>  <?>  <S>)  tries  to  find  every  solution  for  <P>«  Thus 
for  the  first  part  of  the  conjunction,  (IF  Aprea  Aconcl),  what  actually  happens  is  that  LOOKUPS 
returns  all  the  rules  in  the  database  just  as  if  IF  were  an  ordinary  predicate,  and  Aprea  and  Aconcl 
are  bound  appropriately.  Then  for  each  Aconcl  we  find  the  number  of  premises  it  matches  (which 
is  the  number  of  rules  it  can  trigger  in  forward  chaining)  and  BAGOF  returns  a  list  of  these  numbers. 

Carefully  avoiding  insulting  the  reader  with  an  exposition  of  averaging,  the  only  remaining 
problem  is  NoOfMatchingPreaises.  The  approach  is  similar  to  the  outer  loop:  make  a  bag  of  all 
the  rules  in  the  database,  then  find  the  length  of  the  bag;  but  this  time  only  include  those  rules  with 
a  premise  that  matches  the  Aconcl  we’re  looking  at. 

(IF  (AND  (BAGOF  Alhs  ;lhs  is  as  good  as  the  rule  if  we’re  only  counting. 
(AND  (IF  Alhs  Arhs) 

(MatchingPremise  Aconcl  Alhs)) 

Asatchingxules) 

(LENGTH  Amatchingrules  An)) 

(NoOfMatchingPreaises  Aconcl  An)) 

To  write  MatchingPremise,  we  have  to  deal  with  the  two  basic  types  of  premise  the  atomic 
proposition  and  the  conjunction  of  atomic  propositions.  We’ll  ignore  disjunctions  and  more  complex 
forms  for  now. 

Whatever  the  type,  we  must  have  a  way  of  deciding  if  two  propositions  match.  We  can’t  use 
a  because  we  are  comparing  base-level  propositions  and  to  prove  a  the  metsplevel  theorem-prover 
uses  the  meta-level  unifier.  There  is  a  base-level  unification  routine  available  called  batchp,  but  it’s 
a  LISP  function  not  a  built-in  mrs  predicate.  So  there  two  questions  that  spring  to  mind:  firstly, 
how  to  mterface  to  a  LISP  subroutine  so  that  it  looks  like  an  MRS  predicate;  secondly,  how  to 
discover  that  batchp  is  the  name  of  the  function  we  need.  The  answer  to  the  second  question  is 
that  chapter  10  deals  with  all  the  system  routines  available  that  might  useful  to  the  user.  The 
first  question  is  more  tricky. 

Normally,  to  interface  a  LISP  routine  to  make  it  look  like  a  predicate  you  would  use  the  *com- 
putable  representation*  mechanism  or  stash  a  procedural  attachment  for  it  using  totruep  (both 
discussed  in  chapter  8). 

However,  the  meta^level  theorem-prover  is  a  stripped-down  version  that  doesn’t  cater  for  these 
luxuries.  A  cheap  and  cheerful  method  that  works  at  the  meta-level  as  well  as  the  base  level  is  to 
use  the  Done  built-in  predicate: 

(Done  <LISP  •xprt8sion>  <tera>) 

succeeds  if  the  result  returned  from  the  execution  of  the  LISP  expression  unifies  with  the  term. 
Obviously,  any  MRS  variables  in  the  expression  will  be  instantiated  (if  possible)  before  the  call  to 
LISP  is  made.  In  this  case,  we  know  that  batchp  succeeds  if  it  returns  a  list  (as  opposed  to  NIL)  so 


84  The  Compleat  Guide  to  MRS 


we  just  have  to  make  sure  the  term  only  unifies  with  a  list.  After  this  horrendous  plunge  into  detail^ 
we  are  ready  to  write  MatchlngPreaise. 

(IF  (AND  (*■  Alhfl  (AND  .  Apreaisea)) 

(Member  Apreniae  Apreaises) 

(Done  (Batcbp  Apreaise  Aconcl)  (Abindlngs})) 

(MatchingPreBlse  Aconcl  Alhs)) 

(IF  (AND  (UNKNO^^H  («  Alha  (AND  .  Apremiaea))} 

(Done  (Batchp  Alha  Aconcl)  (Ablndinga))) 

(MatchingPreaiae  Accnel  Alha)) 

The  purpose  of  going  through  this  example  in  gory  detail  has  been  not  so  much  to  provide  a 
useful  meta-level  tool  for  database  analysis  (it  would  be  quite  inefficient  to  go  through  this  analysis 
for  every  ASSERT),  but  more  to  show  that  programming  at  the  meta-level  is  no  harder  than  at  the 
base  level,  or  perhaps  I  should  say  just  as  easy.  The  difference  is  simply  that  the  subjects  of  the 
meta-level  predicates  are  facts  instead  of  domain  objects. 

§6.4  Expressing  control  strategies  at  the  meta*level 

In  most  programming  languages,  there  are  instructions  that  achieve  the  necessary  computations  and 
there  are  instructions  that  order  those  computations,  decide  which  to  perform  and  how  often,  and 
in  general  decide  what  gets  done.  The  instructions  look  just  like  the  computational  instructions,  use 
data  structures  such  as  flags,  index  registers,  queues  and  so  on,  and  are  generally  intermingled  with 
and  seldom  distinguished  ln>m  the  rest  of  the  program. 

We  have  already  seen  that  in  MRS  the  concept  of  a  program  as  a  series  of  instructions  is  replaced 
by  the  complementary  ideas  of  knowledge  and  inference.  The  same  process  can  be  applied  to  the 
control  structure  of  a  program.  The  control  structure  is  really  a  procedural  expression  of  metaplevel 
knowledge  about  what  should  be  done  when.  The  natural  course  of  action  in  MRS  is  to  express  this 
knowledge  tx^liciUy  and  use  it  inferentially  to  decide  what  to  do.  In  default  mode,  MRS  just  uses 
depth-first  backward  chaining,  using  facts  and  rules  in  order  of  recency  of  creation,  and  proving 
conjuncts  and  disjuncts  left  to  right.  These  are  all  arbitrary  choices.  Meta-level  control  knowledge 
is  expressed  by  specifying  pre/erences  between  tasks  as  to  which  should  be  done  first,  and  this  is 
sufficient  to  allow  a  broad  range  of  control  strategies  to  be  implemented. 

The  lowest  level  of  task  is  the  single  inference  step.  The  task  preferences  are  expressed  using 
the  predicate  PREFERRED;  thus  when  the  system  has  a  choice  of  tasks,  as  when  more  than  one  rule 
can  be  used  to  prove  a  proposition,  it  tries,  for  each  pair  of  pending  tasks,  to  prove  the  proposition 

(PREFERRED  Ataskl  Atask2) . 

The  preference  relation  induces  a  partiri  ordering  on  the  tasks,  and  the  most  preferred  task  is  chosen 
for  execution.  However,  since  this  mechanism  is  time-consuming  and  not  always  needed,  the  default 
mode  of  operation  ignores  preferences.  The  preferred  flag  should  be  set  to  T  for  this  facility  to 
operate. 

By  using  conditional  preferences,  which  depend  on  arbitrarily  complex  task  properties,  we  can 
create  very  sophisticated  control  structures.  One  limitation  on  the  complexity  is  the  amount  of 
information  available  in  the  task  description;  the  information  can  include  the  context  in  which  the 
task  is  being  invoked,  the  history  of  the  computation  leading  to  the  invocation,  the  available  resources 
for  its  completion,  the  reasons  for  its  invocation  and  so  on.  These  considerations  are  particularly 
important  in  constructing  autonomous  systems  and  new  inference  routines.  The  following  section 
deals  with  a  concrete  task  class. 
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56.5  Control  structure  examples  in  backward  chaining 

Since  backward  chaining  ia  the  usual  theorem-provbg  method  at  the  base  level,  we  will  show  in 
detail  how  task  ordering  can  be  used  to  implement  control  structures  for  it  in  a  number  of  ways. 
The  routine  that  performs  the  single  inference  step  is  bcdisp,  which  has  four  arguments: 


the  list  of  goals  to  be  satisfied. 

«x 

the  binding  list  for  the  variables  m  gl. 

a  justification  list  containbg  the  names  (P123  etc.)  of  the  facts  used  in 
deriving  the  current  gl  from  its  predecessor. 

c« 

a  stack  of  the  goal  lists  preceding  the  current  gl.  Each  list  is  followed 
by  its  corref ponding  j  1. 

Thus,  if  we  had  a  query  Q,  and  a  database  containing 

P112: 

(IF  (AND  A  B  C)  q) 

Pli3: 

A 

and  the  system  had  reached  the  goal  of  proving  B,  the  call  to  bcdisp  would  have  the  following 
arguments: 

fii 

(B  C) 

al 

the  nppropriste  binding  list 

J1 

(P113} 

ce 

((ABC)  NIL  ((AND  A  B  C))  (P112)  (Q)  NIL) 

As  yon  can  see,  it  takes  a  step  to  go  from  a  goal  list  ( (AND  A  B  C) )  to  the  subsequent  list  (A  B  C). 
Now,  given  two  bcdisp  tasks 

(bcdisp  Agll  Aall  AJll  Acsl) 

(bcdisp  Agl2  Aal2  A] 12  katJ), 

how  do  we  express  control  knowledge  as  a  preference  between  them?  Obviously  we  will  use  the 
metai>Ievel  inference  capability  of  MRS  to  make  the  choice  dependent  on  some  condition  on  the  two 
sets  of  arguments: 

(IF  <eondltien  on  both  sets  of  gl.  al,  J1  and  eo> 

(PREFERRED  (bcdisp  Agll  kail  AJll  keel) 

(bcdisp  kgl2  kal2  kjl2  kcs2)}) 

Let  ns  view  the  theorem>proving  process  as  a  search.  If  we  wanted  to  implement  a  breadth'first 
architecture,  rather  than  the  default  depth>first  (e.g.  if  we  wanted  to  guarantee  finding  the  shortest 
proof)  we  would  simply  use  the  condition 

(IF  (AtiD  (LENGTH  keel  kll) 

(LENGTH  kee2  kl2) 

(<  kll  kl2}) 

(PREFERRED  (bcdisp  kgll  kali  kjll  kcsl) 

(bcdisp  kgl2  kal2  kjl2  kce2))} 

since  this  means  that  the  shortest  existing  derivation  path  will  always  be  expanded  first. 
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If  we  wrote  the  length  condition  on  gl  inatead  of  c«  we  would  have  a  simple  best-firat  search, 
baaed  on  the  shaky  but  often  useful  premise  that  »  smaller  number  of  goals  means  a  speedier  solution. 

These  are  the  moat  general  forma  of  preference  imaginable.  We  can  use  more  delicate  instru¬ 
ments;  for  instance,  suppose  we  have  a  search-based  problem-solver  which  uses  a  predicate  (Succ 
$parent  $chlld)  to  generate  successors.  Then  we  can  implement  an  evaluation-based  best-first 
search  as  follows: 

(IF  (AND  (Evaluation  Aparentl  Avl) 

(Evaluation  Aparent2  Av2} 

(>  kvi  Av2)) 

(PREFERRED  (bedisp  ((Succ  Aparentl  Acbildl)  .  Agll)  Aali  AJll  Acel) 
(bedisp  ((Succ  Apartnt2  Achild2)  .  Agl2)  Aal2  AJ12  Icce2})} 

where  presumably  Evaluation  would,  for  efficiency  purposes,  be  a  procedurally  attached  LISP 
function. 

Much  work  remains  to  be  done  on  the  meta-level  expression  of  control  strategies,  but  MRS*s 
capabilities  are  sufficiently  general  that  the  user  should  be  able  to  devise  a  way  to  express  cleanly 
the  control  knowledge  that  she  has. 


Part  II  ; 

Using  the  advanced  features  of  MRS 
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Chapter  7 

Theories:  individually  wrapped  databases 

The  word  ihtoTy  in  MRS  ii  used  to  describe  a  set  of  facts  in  their  own  database.  Up  to  now, 
we  have  treated  all  facts  as  equals,  belongbg  in  one  big,  finite  but  unbounded  database.  With 
the  notion  of  theories  we  can  begin  to  treat  databases  as  objects  in  themselves.  One  of  the  things 
objects  often  have  is  a  name.  The  default  database  you  have  been  usbg  to  far  is  called  the  global 
theory.  All  the  facts  b  it  know  they're  there:  the  proposition  symbol  for  each  fact  has  on  its  theory 
property  the  word  global. 

Clearly,  the  bumbg  question  is  *Why  would  I  want  to  havt  more  than  one  theory?*.  Well,  the 
technical  use  of  the  term  is  not  to  far  from  the  everyday  meanbg;  if  you  have  more  than  one  theory 
about  somethbg  then  you  can  use  more  than  one  theory  to  keep  your  theories  m.  The  competbg 
theories  might  be  as  difi^erent  as  the  wave  and  particle  theories  of  light,  or  the  FVeudian  and  Gestalt 
theories  of  human  behavior;  or  they  might  just  describe  different  hypothetical  situatbns  b  a  search 
space.  Another  common  use  of  theories  h  hr  efficiency  purposes.  If  one  is  solvbg  mathematical 
pussies  then  there  is  no  need  to  search  fc?  rrhs  and  facts  through  an  encyclopaedic  collection  of 
knowledge  about  the  lives  of  composers  and  ecclesiastical  architecture  that  might  be  present  b 
a  global  theory.  By  dividbg  the  total  knowledge  bto  different  areas,  one  achieves  an  automatic 
focusbg  of  attention  onto  the  relevant  information  if  the  appropriate  theories  are  used. 

The  key  idea  is  that  the  ability  to  treat  sets  of  facts  as  objects  gives  the  ability  to  compare,  select, 
rank,  exclude,  divide,  combbe,  distbguiah  and  otherwise  mess  around  with  bodies  of  knowledge, 
thus  conferring  upon  the  user  a  rich,  new  opportunity  for  the  manipulation  of  information. 

|7.1  Getting  tacts  into  and  out  of  theories 

As  mentioned  above,  sU  facts  stashed  by  the  user  go  by  default  into  the  theoiy  global.  This  is 
because  global  is  the  initial  value  of  the  variable  theory,  which  determbes  the  current  default 
theory  for  stashbg.  Thus  to  create  a  new  theory  one  can  set  the  value  of  theory  and  start  stashbg. 
A  alternative  to  use  the  foUowbg  theory-specific  versions  of  the  standard  database  routbes: 

thassert  (thaseert  <p>  <th>)  asserts  <p>  b  theory  <th>  and  sets  the  value 

of  theory  to  <th>. 

thunassert  (thunassert  <p>  <th>}  unasserts  <p>  from  theory  <th>  and  sets 

the  value  of  theory  to  <th>. 

thstash  Rather  like  thaseert. 

thunstash  Rather  like  thunassert. 

A  theory  can  be  emptied  by  callbg  empty  on  it.  One  can  also  create  a  whole  theory  at  one  go 
by  saybg 

(dtf theory  <th>  <pi  >  >) 

which  first  empties  <th>  and  then  asserts  the  propositions  bto  it. 

$7.2  Selecting  which  theories  to  use 

Havbg  a  current  default  theory  for  stashbg  is  all  very  well  but  when  it  comes  to  dobg  a  lookup 
one  might  want  to  have  more  than  one  theory  accessible.  The  value  of  the  variable  actiyethsorles 
is  a  list  of  the  theories  which  are  available  to  lookup.  The  global  theory  b  always  avallabb.  Thus 
you  can  set  the  value  of  activetheories  yourself  or  itse  the  commands 
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(activatu  <thi  >  •••  <thn  >) 
which  adds  the  specihed  theories  to  the  active  list,  and 
(deactivata  <tbi  >  . , .  <thn  >) 
which  tahes  them  off  the  active  list. 

The  user  can  specify  a  representation  for  a  class  of  propositions  that  is  specific  to  a  given  theory 
by  asserting 

(threpn  <p>  <xpa>  <th>) . 

This  will  be  effective  whOe  <th>  is  active.  One  should  be  aware  that  the  result  of  a  lookup  on  a 
fact  which  has  two  different  representations  in  two  active  theories  is  undefined. 

The  subroutine  (contents  <th>)  prints  out  a  list  of  the  pr  facts  in  a  theory,  each  preceded 
by  its  associated  proposition  symbol. 

{7.3  Related  theories 

Suppose  we  have  a  general  theory  LogiePrograaning  and  some  specific  theories  such  as  MRSPro- 
graaaing  and  PROLOGPrograaaing.  All  of  the  facts  in  the  specific  theories  are  notionally  part  of  the 
subject  matter  of  logic  programmig;  thus  when  we  activate  LogicPrograamlng  we  would  like  the 
language-specific  facts  to  be  a>^rlable  also  without  having  to  duplicate  them  in  the  overall  theory  or 
^  activate  each  subtheory  explicitly.  MRS  allows  the  user  to  do  just  this  (surprise,  surprise)  by  simply 

asserting 

(includes  ’LogiePrograBalng  ’MRSPrograaalng) 

and  so  on.  The  effects  can  be  undone  by  asserting  an  unincludes  fact  for  the  pair  of  theories, 
includes  and  unincludes  are  also  available  as  subroutines  which  can  be  called  with  the  theories 
as  arguments,  giving  greater  efficiency. 
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Chapter  8 

Procedural  attachment 

Procedural  attachment  ii  a  term  which  denotee  the  interfacing  of  procedural  information  (i.e. 
applicative  or  imperative  codie)  to  a  declarative  eye  tern.  The  purpose  is  to  achieve  greater  efficiency 
for  certain  operations  at  the  expense  of  the  generality  and  explicitness  provided  by  the  mechanisms 
of  deduction. 

Procedural  attachments  in  MRS  come  in  two  flavonre:  the  first  type  might  be  called  task*related 
and  involves  the  replacement  of  system  functions  for  say  proof  or  retrieval  with  speciai-pnrpose  user 
code  or  other,  non-standard  routines;  the  second  type  is  predicate-related,  involvmg  replacing  the 
normal  deductive  or  look-up  procedures  for  certain  predicates  with  programs  that  achieve  the  same 
end  with  greater  speed  or  using  less  space* 

|8.1  Task-related  attachment 

For  any  given  top-level  system  task  <T>,  the  user  can  designate  the  LISP  function  to  perform  it 
for  arguments  matching  a  pattern  by  stashing  a  fact  of  the  form 

(to<T>  <pattern>  <function  nano) « 

As  previously  mentioned,  after  the  task  is  invoked  by  the  user  MRS  will  attempt  to  find  out  how  to 
perform  it  by  looking  for  just  such  to<T>  facts  in  the  database.  A  precautionary  note:  since  only 
one  way  of  performing  a  task  is  needed,  MRS  will  just  use  the  first  one  it  finds;  the  fact  that  the 
metvlevel  theorem  prover  does  a  lookup  before  trying  rules  means  that  unconditional  propositions 
will  always  have  precedence  over  rules,  so  default  procedures  may  have  to  be  unstashed  before 
conditional  attachments  become  effective.  For  instance,  the  default  assertion  method  is  stored  as 

(toassert  kp  pr-’stash) 

so  if  you  wanted  to  add  a  conditional  fact  such  as 

(IF  (FC-Desirable  kp)  (toassert  kp  fc)) 

you  should  first  either  remove  the  default  by  unstashing  it,  or  replace  it  with  a  conditional  default 
whose  antecedent  it  always  true  (the  standard  one  is  (•  T  T)). 

The  tasks  for  which  this  mechanism  is  implemented  are  as  follows: 


(un) assort 

lookup (s) 
(un) stash 
trutp(s) 

cache 

edit 

Bonitor(s) 


Usual  choice  is  whether  to  forward-chain  or  not.  (Tertam  ‘system*  facts 
require  special  routines,  e.g.  (toassert  (rtpn  •  kx)  repa-assert). 
Each  representation  method  also  has  its  own  routine. 

Representation-dependent. 

Representation-dependent. 

To  procedurally  attach  particular  predicates  or  changt  ths  inference 
method. 

Special  case  —  invoked  automatically  but  otherwise  like  stash.  See 
chapter  11  for  a  discussion  of  caching. 

To  specify  the  editor  to  be  used  for  direct  database  editing  (see  chapter 

12). 

To  affect  how  database  assertions  are  monitored  (see  chapter  12). 
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output  (a)  To  affect  how  facU  are  displayed  (see  chapter  12). 

Not  all  of  these  tasks  can  be  handled  independently.  If  a  fact  is  stashed  using  a  non-standard 
representation,  it  must  be  retrieved  using  the  appropriate  routine  for  that  representation.  Such 
co-ordinated  changes  are  best  handled  using  the  repn  mechanism  described  in  the  next  chapter.  In 
that  chapter  we  also  deal  with  the  alternative  inference  routines  available,  some  of  which  require 
specialised  representations  also. 

§8.2  Predicate^related  attachment  ~  built-in  predicates 

As  we  have  already  seen,  some  predicates  in  MRS  are  evaluable;  that  is,  they  are  not  defined  by 
rules  or  simple  facts,  but  have  computable  truth  conditions.  The  arithmetic  relations  are  the  prime 
examples.  Equality  may  also  be  viewed  as  a  computable  predicate,  with  a  procedural  attachment 
to  the  unification  routine.  The  predicates  for  handling  sets  and  lists,  including  length,  are  also 
evaluable. 

These  predicates  are  all  attached  using  tolookup(s)  and  totruep(s)  facts  which  are  in  the 
initial  MRS  database.  You  can  inspect  these  facU  by  calling  PRPACTS  on  the  predicate  in  question. 

(*  xi . .  jcn  y)  succeeds  if  y  unifies  with  the  product  of  xi . .  jc«. 

(+  xx .  •  On  y)  succeeds  if  y  unifies  with  the  sum  xx . . 

(*  X  y  x)  succeeds  if  z  unifies  with  the  difference  of  x  and  y. 

(//  X  y  x)  succeeds  if  z  unifies  with  the  quotient  of  x  and  y. 

(<  X  y)  succeeds  if  x  is  less  than  y. 

(>  X  y)  succeeds  if  x  is  greater  than  y« 

(<*  X  y)  succeeds  if  x  is  less  than  or  equal  to  y. 

(>*  X  y)  succeeds  if  x  is  greater  than  or  equal  to  y. 

(Dia J  oint  x  y)  succeeds  if  the  lists  x  and  y  have  no  common  elements. 

(Done  X  t)  succeeds  if  the  result  returned  from  executing  the  LISP 
expression  x  unifies  with  the  term  t. 


m 

♦ 

// 

< 

> 

<- 

>■ 

Disjoint 

Done 


Element 

Element 8 In 

Inter 

Intersect 

MAnd 

KAndCan 

MAndCar 

Member 

MemList 

SetDiff 


(Element  x  1}  succeeds  if  the  object  x  is  an  element  of  list  1. 

(Elementsln  b  s)  succeeds  if  s  is  the  set  of  elements  in  bag  b. 

(Inter  x  y  x)  succeeds  if  x  is  the  intersection  of  lists  x  and  y. 

(Intersect  x  y)  succeeds  if  lists  x  and  y  have  a  non-empty  intersection. 

(MAnd  p  1)  succeeds  if  predicate  p  is  true  of  every  element  in  list  1. 

(MAndCan  pis)  succeeds  if  s  is  the  union  of  the  lists  y  that  satisfy  (p 
X  y)  for  each  elememt  in  list  1. 

(MAndCar  pis)  succeeds  if  s  is  the  set  of  objects  y  that  satisfy  (p  x 
y)  for  each  elememt  in  list  1. 

is  a  synonym  for  Element. 

is  a  synonym  for  Element. 

(SetDiff  X  y  z)  succeeds  if  z  is  set  difference  of  x  and  y. 
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Subset  (Subset  x  y)  succeeds  if  x  is  a  subset  of  y. 

Union  (Union  x  y  s)  succeeds  if  z  is  the  list  formed  by  appending  x  and  y. 

Another  class  of  evaluable  predicates  is  that  of  the  metalinguistic  predicates  —  predicates 
dealing  with  relations  outside  of  the  object-level  universe  that  treat  their  arguments  as  syntactic 
objects  without  reference.  Because  of  this  property,  one  could  only  implement  these  predicates  in 
*pure’  logic  programming  by  tuing  a  vast  table  of  all  the  tuples  satisfying  the  predicate.  Strictly 
speaking,  the  arithmetic  predicates  are  also  in  this  class.  It  includes  the  (self-explanatory)  arithmetic 
predicates  integer  and  number,  and  the  numeric  equality  predicate  nua**.  This  predicate  works 
exactly  like  •  except  that  when  both  its  arguments  are  numeric  it  performs  a  comparison  with  a 
tolerance  given  by  the  value  of  &ua***thre ahold,  which  is  initially  O.CXX)!.  Two  other  predicates 
allow  examination  of  the  binding  status  of  variables  and  expressions: 

Variable  (Variable  <x>)  succeeds  if  <x>  is  a  currently  unbound  variable. 

Ground  (Ground  <p>)  succeeds  if  the  expression  <p>  contains  no  unbound 

variables. 

A  nice  example  of  the  use  of  Variable  and  Ground  is  the  following  (partial)  implementation  of  an 
addition  predicate  that  handles  uninstantiated  arguments: 

(IF  (AND  (Ground  $y) 

(Ground  $z) 

(Variable  $x) 

(-  $*  ly  $x)) 

(+  $x  $y  $z)) 

To  facilitate  interaction  between  MRS  and  LISP  programs,  a  predicate  (Value  <x>  <v>)  is 
provided  which  succeeds  when  <v>  is  unifiable  with  the  value  of  <x>.  Also  (Property  <x>  <v> 
<p>)  succeeds  when  <x>  has  value  <v>  for  property  <p>.  Assertbg  a  Property  or  Value  fact 
has  the  effect  of  setting  the  property  or  value. 

§8.3  Fredlcate«related  attachment  —  computable  representations 

The  computable  representation  mechanism  in  MRS  allows  the  user  to  specify  classes  of  proposition 
for  which  the  result  of  a  lookup  (and  hence  of  a  trucp)  is  computed  by  a  LISP  subroutine,  which 
will  be  known  as  the  associated  LISP  subroutine  (or  ALS)  for  that  class. 

This  is  achieved  by  asserting  a  fact  of  the  form 

(rtpn  <p>  <rpn>) 

which  means  that  propositions  matching  <p>  will  be  handled  using  the  computable  representation 
<xpn>.  The  assertion  of  the  repn  fact  causes  a  tolookup  and  a  tolookups  fact  to  be  stashed  for 
the  proposition  class,  which  attaches  it  to  the  appropriate  interface  routines  which  call  the  ALS  and 
then  package  the  results  into  the  proper  binding  list  format  expected  by  the  theorem  prover. 

The  ALS  must  be  on  the  LISP  property  of  the  predicate  involved,  so  one  must  assert  the  fact 

(Property  <pred>  <ALS>  LISP)  • 

The  <rpn>  value  used  will  be  a  mnemonic  code  specifying  how  the  arguments  are  to  be  handled, 
whether  a  value  is  to  be  returned,  whether  binding  lists  are  to  be  tingle  or  multiple  and  so  on.  The 
code  will  determine  the  interface  routines  to  which  the  predicate  will  be  attached.  The  rest  of  thb 
section  deals  with  the  codes  that  MRS  provides. 
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The  biaic  thing  to  decide  la  whether  the  LISP  routine  i«  to  return  a  value  that  is  a  function 
of  its  arguments,  or  to  act  as  a  predicate  in  itself  (c.g.  FLOAT?).  All  function  codes  begin  with 
F,  all  predicate  codes  begin  with  R  (for  Relation),  if  you  always  want  a  given  predicate  to  be 
proccduxally  attached  regardless  of  its  arguments  you  can  replace  the  repn  and  DEFPROP  entries 
above  by  asserting 

(relnproc  <prtd>  <ALS>  <rpn>) 
for  relations  or 

(funproc  <pred>  <ALS>  <rpa>) 
for  functions. 

Suppose  we  decide  that  the  LISP  routine  is  to  return  a  value.  The  <rpxi>  code  will  begin 
with  F.  MRS  predicate  will  need  to  have  an  extra  argument  which  will  be  unified  with  the  result 
when  the  function  returns.  Thus  a  LISP  function  (f  xi ..  jtn)  will  be  attached  to  a  predicate  (1 
Xi..  jCn  y),  and  y  will  be  unified  with  the  result  returned  by  the  function  f.  Often,  we  will  want 
to  use  arguments  which  are  themselves  functional  expressions,  MRS  allows  for  this  in  the  second 
letter  of  the  code  which  is  £  or  Q.  Q  (fer  Quote)  means  that  the  arguments  are  passed  ‘as  is’  to 
the  subroutine.  E  (for  Eval)  means  that  arguments  which  are  terms  beginning  with  predicates  that 
have  functional  attachments  are  treated  like  functional  expressions  and  evaluated  by  calling  lookup 
on  them  with  an  extra  argument.  An  example  will  make  this  clearer.  Suppose  we  have  a  predicate 
(Average  $a  $b  $avg)  which  we  want  to  attach  to  a  LISP  function  (Average  a  b).  If  we  declare 
the  predicate  as  having  representation  FE,  then  we  can  ure  K  cx  any  other  FE  or  FQ  predicate, 
functionally  as  its  first  or  second  argument: 

(Average  (Average  2  4)  6  $x) 

would  succeed  with  $x  bound  to  4.  As  one  might  expect,  we  can  also  handle  the  case  where  we 
want  to  perform  a  niua—  unification  on  the  result  rather  than  a  straightforward  To  do  this,  use 
a  third  code  letter  A  (for  Arithmetic).  We  would  probably  want  this  for  the  averaging  predicate 
so  we  would  declare  it  by  saying 

(ASSERT  * (funproc  Average  Average  FEA}). 

Now  for  the  computable  relations,  which  are  a  little  more  complicated.  The  first  letter  of  the 
code  will  be  R;  the  ALS  will  have  the  same  number  of  arguments  as  the  predicate  The  second  letter 
is  still  E  or  Q  as  above.  Plain  RE  and  RQ  relations  are  treated  just  as  you  would  expect:  if  the  LISP 
routine  returns  NIL  the  lookup  (or  truep)  fails;  if  it  returns  a  non-NIL  value  the  lookup  returns 
((T  •  T)).  For  example,  to  attach  FLO  ATP  we  would  probably  use  the  RE  representation: 

> (ASSERT  ‘(relnproc  FLOAT?  FLOAT?  RE)) 

DONE 

>(TRUE?  ‘(FLOAT?  1.34)) 

NIL 

Often  we  will  want  to  be  able  to  handle  procedural  attachments  for  predicates  whose  arguments 
may  be  unbound  variables  —  the  ALS  will  produce  the  correct  bindings  for  the  variables  and  return 
the  appropriate  binding  list.  If  we  add  a  B  (for  Binding)  as  the  third  letter  of  the  code,  this  means 
that  the  ALS  will  return  its  own  bmding  list  (or  NIL).  Using  this,  we  could  write  an  averaging 
predicate  that  worked  when  say  the  first  argument  was  unbound.  To  return  binding  lists,  the  ALS 
(and  not  MRS)  will  need  to  test  its  arguments  to  see  if  they  are  variables,  perform  the  appropriate 
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computation  accordingly  and  constnict  a  binding  liat  to  return.  This  b  made  easier  by  the  availabllty 
of  the  system  functions  for  handling  variables  and  binding  lists,  which  are  described  in  chapter  10. 

> (ASSERT  •(rclnproc  Average  AvtrageP  REB)) 

DONE 

> (DEFUN  Average?  (x  y  avg) 

(COND  ((AND  (NUl^SR?  x)  (NlHiBERP  y)) 

(batchp  (QUOTIENT  (TIJSS  x  y)  2)  avg)) 

({AND  (NUK3ERP  x)  (blvarp  y)  (NUl-CBERP  avg)) 

(batchp  (DIFFERENCE  (PLUS  avg  avg)  x)  y)) 

((AND  (blvarp  x)  (NUKBERP  y)  (NUMBER?  avg)) 

(batchp  (DIFFERENCE  (PLUS  avg  avg)  y)  x)))) 

AVERAGE? 

>(TRUZP  »(Averaga  lx  3  4)) 

(($X  .  5)  (T  .  T)) 

In  some  cases,  REB  and  RQB  relations  will  want  to  return  multiple  solutions,  for  instance  if  we  had 
a  quadratic  solver  (Quad  la  $b  |c  |x)  which  might  want  to  return  0,  1  or  2  different  bindings  for 
lx.  To  do  this,  add  a  fourth  letter  M  (for  Multiple). 

There  exists  one  extra  type  of  attachment  which  is  a  hybrid  of  the  functional  and  relational 
classes.  The  RQFM  representation  allows  for  ALS  routines  which  operate  like  functions  on  the  first 
n  —  1  arguments  but  return  a  simple  list  of  values  which  are  to  be  interpreted  as  alternatives.  The 
RQFM  designation  will  cause  a  multiple  binding  list  to  be  automatically  constructed  for  the  last 
argument  (If  unbound);  if  bound,  the  predicate  will  succeed  if  the  last  argument  unifies  with  any  of 
the  returned  values. 

Thus,  in  summary,  the  available  ways  of  getting  LISP  programs  to  do  the  work  of  predicate  are 
F£,  FQ,  F£A  for  functions  returning  values,  RQFM  for  multifunctions,  and  RE,  RQ,  REB,  RQB, 
REBM,  RQBM  for  relations. 

To  create  one’s  own  computable  representation  (if  one  can  think  of  any  other  possibilities,  that 
is)  one  should  assert  a  fact  of  the  form 

(repn-netbod  <rpn>  <op>  <method>) 

for  the  <op>t  lookup  and  lookups,  where  the  <aethod>  is  an  appropriate  interface  routine. 
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Chapter  9 

Alternative  representations  and  inference  procedures 

For  certain  computations  and  certain  classes  of  facts,  s  representation  other  than  the  standard 
MRS  indexed  list  structure  is  useful,  and  several  such  representations  are  provided.  Moreover, 
some  problems  are  best  solved  using  inference  procedures  other  than  backward  chabing  with  modus 
poftcns.  In  some  cases  these  procedures  operate  with  the  standard  representation,  in  others  they  use 
specialised  forms. 

§9.1  Representations 

The  representations  discussed  here  are  essentially  storage  and  retrieval  methods  for  facts,  and  af¬ 
fect  how  the  stored  facts  appear  internally.  If  the  database  routines  are  well-written,  the  chosen 
representation  need  have  no  effect  on  the  external  appearance  of  the  facts  at  aU.  A  specific  represen¬ 
tation  can  be  viewed  as  an  implementation  of  an  abstract  data  type  with  the  operations  atash  anu 
lookup.  Different  representations  are  more  or  less  efficient  for  these  operations  for  different  classes 
of  facts.  MRS  allows  the  user  to  specify  that  all  facts  matching  a  pattern  <p>  should  be  stored 
using  representation  <rpa>  by  asserting  a  fact  of  the  form 

(repn  <p>  <rpn>) . 

The  effect  of  this  is  to  cause  the  appropriate  tolookup  and  toetaeh  facts  to  be  entered  into  the 
database.  Since  these  facts  operate  at  the  meta-level  the  pattern  <p>  must  use  meta-level  variables. 
The  currently  implemented  representations  are: 

The  default;  each  fact  is  stored  verbatim  on  the  pattern  property  of  a 
unique  proposition  (e.g.  P123).  The  facts  are  then  fully  indexed  on  every 
position  in  the  list  structure  of  the  fact.  Only  pr  facts  are  accessible  to 
the  full  range  of  theory-related  commands  (see  chapter  7), 

Conjunctive  normal  form;  b  this  representations  all  facts  are  stored  as 
disjunctions  of  literals  (a  literal  is  an  atomic  proposition  or  the  nega¬ 
tion  of  one).  The  whole  database  is  an  implicit  conjunction  of  these 
disjunctions,  hence  the  name.  For  example,  (IP  A  B)  is  stored  as  the 
disjunction  of  (NOT  A)  and  B,  This  representation  is  used  by  the  resolu¬ 
tion  routbes. 

dnf  Disjunctive  normal  form;  like  CNF,  but  the  database  is  a  disjunction 

of  conjunctions  of  literals.  One  can  write  a  DNF  resolution  routbe  if 
desired. 

P^  Property  list  representation;  useful  for  storbg  the  values  of  unary  func¬ 

tions  on  (or  attributes  of)  concepts;  for  example,  (Arity  Meaber  2)  is 
stored  by  puttbg  2  on  the  Axity  property  of  Mtaber. 

»  useful  for  storbg  unary  relations  such  as  (IsYonderful  MRS). 

“  useful  for  storbg  many-many  binary  relations  such  as  SaaeAge. 

For  example,  suppose  we  wanted  to  use  a  lot  of  facts  about  people’s  ages.  Sbcc  age  is  a 
many-one  relation,  we  would  use  the  pi  representation  for  efficiency.  To  achieve  this,  enter 

(ASSERT  ’ (repn  (Age  Ax  Ay)  pi) ) . 

Then,  when  we  say 
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(STASH  '(Age  Nuncy  91)) 

the  attribute  U  stored  directly  on  Najicy’s  property  list: 

(PLIST  ►Nancy) 

(Age  91) 

TLe  tl  representation  also  nse§  the  property  list  directly,  by  putting  a  T  on  the  appropriate  property 
of  the  concept  involved.  The  dl  representation  usee  properties  with  multiple  values  stored  as  a  list; 
for  example,  the  property  list  of  Henry  Vm  might  end  up  as 

(HasVife  (KathaxineOfA  AnneB  JeneS  AnseOfC  CatherineH  KathtrineP}) . 

With  each  of  these  property  list  representations  the  queries  can  have  only  the  value  uninstantiated, 
and  variables  In  the  facts  will  not  be  Handled  properly.  This  is  an  example  of  the  generality/ efficiency 
trade»off  common  in  representations  (and  procedures  for  that  matter). 

The  user  can  create  her  own  representations  by  specifying  the  storage  and  retrieval  routines  for 
it;  to  do  this  one  asserts  facts  of  the  form 

(repn-^method  <rpn>  <op«ration>  <routint>) 

for  the  operations  lookup,  lookups  and  stash.  As  an  example,  we’ll  take  the  case  of  storing 
attributes  of  objects  identified  by  number,  for  instance  a  database  of  ciutomer  attributes  using  facts 
like 

(CustomerNass  3423  (John  Q  Public)). 

To  have  these  facts  stored  in  an  array,  with  its  mstant^access  advantages,  we  would  say 

(ASSERT  • (repa-nethod  ar  lookup  ar*lookup)) 

(ASSERT  *  (repn-'&ethod  ar  lookups  ar**lookup8)) 

(ASSERT  *  (repn-method  ar  stash  ar^stash)) 

(defun  ar*lookup  (p) 

(batchp  (caddr  p)  (f uncall  (car  p)  (cadr  p)))) 

(defun  ar-lookups  (p) 

((laabda  (bl)  (cond  (bl  (list  hlj)  (t  nil)))  (ar-lookup  p))) 

(defun  ar*stash  (p) 

(apply*  ►store  (list  (car  p)  (cadr  p))  (caddr  p))) 

(ASSERT  ’(xepn  (CustoaerNa*9s  Anuaber  Anaae)  ar)) 

Notice  that  the  above  routines  only  work  if  the  customer  number  is  already  known.  If  this  were 
not  the  case,  they  would  have  to  be  extended  handle  queries  such  as  (CustoaerKaae  $n  (A  N 
Other))  by  recognizing  that  the  first  argument  to  the  predicate  was  a  variable  ard  then  searching 
the  entire  array  to  find  the  index  number  for  the  given  customer;  for  this  class  of  query  the  array 
representation  would  be  extremely  inefficient.  One  solution  would  be  to  have  ar*asstrt  store  the 
fact  in  both  ar  and  pr  representations,  and  have  ar* lookup  choose  which  to  use  according  to  the 
bbding  status  of  the  arguments  in  p. 

§9.2  Alternative  inference  procedures 

MRS  provides  several  modes  of  inference  other  than  the  standard  backward  chaining.  Each  is 
appropriate  for  a  fairly  ill-defined  range  of  situations  and  deciding  which  to  use  is  still  something  of 
an  art.  As  with  almost  anything  else,  the  user  can  write  her  own  inference  routines;  the  simplest  to 
implement  will  be  of  the  ►black-box’  type,  which  take  a  proposition  as  argument  and  return  a  binding 
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list.  They  will  be  invoked  u^ing  a  totruep  attachment  and  their  internal  workings  will  avoid  the 
use  of  the  scheduler  architecture.  All  of  the  MRS-provided  routines  are  of  the  non-black-box  kind, 
putting  their  individual  inference  steps  on  the  agenda  so  that  the  user  can  create  control  strategies 
to  increase  efHtiency. 

Forv/nrd  cHaining 

Forward  chaining  has  already  been  covered  in  an  earlier  chapter.  There  only  remains  to  describe 
the  task  structure.  The  inference  step  task  is  very  simple: 

(fedisp  p) 

where  p  is  the  proposition  to  be  asserted  and  from  which  the  forward  chaining  will  take  place. 
Multiple  possibilities  occur  when  a  fact  satisfies  the  premise  of  more  than  one  rule,  so  that  f  edisp 
tasks  arc  placed  on  the  agenda  for  each  of  the  rule  conclusions.  A  typical  control  strategy  would 
give  preference  to  the  conclusion  most  likely  to  contribute  to  the  desired  goals. 

9.2.2  Residue 

The  residue  routine  operates  in  a  backward  chaining  fashion,  the  difference  from  the  usual 
truep  method  being  that  it  is  allowed  to  assume  the  truth  of  propositions  contained  in  assuaable 
statements,  or  which  can  be  proved  to  be  assuaable.  Thus,  if  one  stashes  a  fact  (assumable  <q>), 
then  a  call  to  (residue  <p>)  will  do  a  backward-chaining  proof  of  <p>  and  in  doing  so  assume 
that  <q>  is  true.  A  list  of  all  the  facts  assumed  in  the  proof  of  <p>  is  returned  (residues  <p>) 
retiims  all  possible  lists  of  such  facts.  Each  list  of  facts  is  called  the  residue  of  <p>. 

That’s  all  very  simple  and  straightforward  Tm  sure.  What  is  not  so  clear  to  the  uninitiated  is 
what  it’s  all  for.  Well,  one  use  is  for  the  expression  of  default  rules,  A  typical  example  might  be 

(IF  (AND  (Bird  $b)  (UNPROVABLE  (NOT  (Flies  $b))) 

(assumable  (Flies  $b))}. 

The  use  of  residues  and  assumable  facts  has  several  advantages:  default  assumptions  upon  which  a 
solution  is  based  are  distinguished  horn  solid  facts;  the  user  is  given  a  list  of  assumptions  which  he 
can  check  for  validity  in  the  individual  cases;  the  addition  of  an  exception  to  the  database  such  as 

(NOT  (Fliee  OllyTheOelrich) ) 

will  not  invalidate  the  rule,  whereas  if  the  conclusion  were  definite  and  not  just  assumable  contra¬ 
dictions  could  arise,  particularly  if  forward  chaining  or  caching  were  in  operation. 

A  second,  and  perhaps  the  major,  use  of  residues  is  for  synthesis  of  complex  objects  from 
specifications.  For  instance,  we  coula  take  the  rules  for  circuit  behavior  from  chapter  5,  tell  the 
system  it  could  assume  any  connections  it  wanted  and  call  residue  on  the  desired  i/o  pair  and  have 
it  return  the  circuit  it  needed  to  assume  to  get  the  required  behavior,  described  by  a  list  of  assumed 
facts  looking  very  much  like  the  descriptions  of  circuits  as  defined  by  the  user.  That,  at  least,  is  the 
idea. 

Residues  are  implemented  by  the  subroutine  br.  The  task  step  is 
(brdisp  gl  al  theory  J1  ce) 

where  all  the  arguments  are  the  same  as  for  bedisp  except  for  theory,  which  contains  the  assump¬ 
tions  made  so  far  in  deriving  the  goal  list  gl. 


9.2.8  Resolution 
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Unlike  modus  poncns^  the  resolution  inference  rule 


{OR  Aj 

{OR  Ax » •  •  Ai^x  1  •  •  •Affi  J3x  **•  i  ■^y+x  •  • 


where  Aicr  =  {NOT  Bja)  or  vice  versa 


is  completfi  i.e.  all  possible  logical  conclusions  of  a  set  of  facts  can  be  drawn  usbg  the  rule.  This  is 
probably  the  major  reason  why  one  would  use  it.  FVom  the  definition  two  drawbacks  are  immediately 
appar^^nt.  Firstly,  the  rule  itself  is  rather  cumbersome  and  unintuitive  in  the  sense  that  that  normal 
human  modes  of  reasoning  do  not  fit  it  welL  Secondly,  it  requires  that  the  database  be  in  CNF,  which 
often  renders  facts  unintelligible  and/or  greatly  increased  in  sise.  However,  for  such  applications 
as  mathematical  theorem-proving,  resolution  is  still  the  method  of  choice,  since  with  resolution  one 
does  not  need  to  worry  about  the  incompleteness  or  directionality  of  repesentation  inherent  in  a  rule- 
based  system.  With  MRS*s  ability  to  convert  facts  to  CNF  automatically,  resolution  is  a  serious 
candidate  for  many  applications.  To  prove  a  proposition  using  this  method,  the  user  should  simply 
enter 


(resolution  <p>) 

and  the  binding  list  will  be  returned  just  as  with  truep.  resolutions  needs  no  further  comment. 
What  happens  is  that  <p>  is  first  negated,  then  added  to  the  database  in  CNF.  Resolutions  are 
then  performed  until  an  empty  disjunction  is  created,  signifying  a  contradiction.  The  rest  of  the 
database  can  be  created  in  CNF  by  starting  off  with 

(ASSERT  »(repn  kp  caf)) 

which  causes  all  subsequently  entered  facts  to  be  stored  in  normal  form,  and  all  retrievals  to  be 
performed  accordingly. 

The  default  strategy  used  is  a  set-of-support,  linear*  input  strategy.  The  set-of-support  strategy 
is  the  resolution  equivalent  of  backward-chaining:  only  resolutions  involving  a  goal  clause  or  a  clause 
whose  derivation  includes  a  goal  clause  are  considered. 

The  standard  resolution  routine  is  rs,  and  the  single  inference  step  is 

(rsdisp  gl  al  theory) 

where 

is  a  list  of  the  clauses  produced  so  far  by  resolution  with  the  original 
negated-goal  clauses  ^ 

al  is  the  binding  list  for  the  variables  in  gl; 

theory  is  a  locally-bound  theory  containing  the  original  goal  clauses. 

0.2.4  Resolution  with  residues 

resolutionresidue  and  resolutionresidues  operate  exactly  as  one  would  expect,  performing 
resolution  with  assumptions  returned,  rr  is  the  standard  routine,  the  inference  step  is 

(rrdisp  gl  cl  al  theory) 

where  ;he  arguments  are  the  same  as  for  resolution  with  the  addition  of  cl  which  is  the  list  of 
assumptions  made  in  deriving  gl. 
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Chapter  10 

Useful  system  functions 

There  are  several  places  where  the  user  will  want  to  write  tome  additional  code  of  her  own  to 
tailor  the  system  to  her  needs.  These  include  writing  procedural  attachments  for  predicateSi  new 
computable  representation  interfaces,  new  representation  storage  and  retrieval  routines,  formatting 
and  filtering  routines  for  returned  solutions  and,  last  but  not  least,  new  inference  routines.  Since 
MRS  itself  does  all  of  these  things,  it  is  not  surprising  that  it  contains  a  lot  of  useful  subroutines 
which  are  also  available  to  the  user. 


SlO.l  Testing  for  variables 

In  attached  LISP  subroutines,  inference  routines  and  often  in  ordinary  MRS  predicates  one  will  want 
to  test  expressions  to  see  if  they  are  ground  or  variable. 


blvarp 

(blvarp  x)  returns  T  if  x  is  a  base-level  variable,  i.e.  an  atom  beginning 
with  $. 

alvarp 

(mlvarp  x)  returns  T  if  x  is  a  meta-level  variable,  Le.  an  atom  beginning 
with  k. 

varp 

(varp  x)  returns  T  if  x  any  kind  of  variable. 

gxoundp 

(groundp  x)  returns  T  if  x  is  an  expression  containing  no  variables. 

$10.2  Matching  and  unification 

These  routines  will  come  in  useful  in  roughly  the  same  areas  as  the  variable  testing  routines.  The  one 
that  is  needed  will  depend  on  the  level  (base-  or  meta»)  and  the  (non)  necessity  for  standardization 
of  variables. 

batchp 

(batchp  X  y)  is  a  base-level  unification  routine  that  standardizes  vari¬ 
able*.  first,  and  returns  the  binding  list  (if  any)  for  the  variables  in  x. 

Batchp 

(matchp  X  y)  is  a  meta-level  unification  routine  that  standardizes  vari¬ 
ables  first,  and  returns  the  binding  list  (if  any)  for  the  variables  in  x. 

samep 

(saaep  x  y)  is  a  base-level  routine  that  returns  a  binding  list  for  the 
variables  in  x  if  the  two  expressions  are  the  same  up  to  variable  renaming. 

unifyp 

(unifyp  X  y)  is  a  base-level  unification  routine  that  letums  the  most 
general  unifier  of  x  and  y  (if  any)  but  does  not  distinguish  occurrences 
of  the  same  variable  in  the  two  expressions. 

§10.3  Binding  lists 

Along  with  multiple  uses  in  inference  routines  and  attached  predicates,  the  functions  for  binding  list 
manipulation  are  very  useful  for  formatting  the  solutions  returned  by  truep. 

gttTar 

(gttvar  X  bl)  returns  the  binding  for  variable  x  from  binding  list  bl. 

getbdg 

(getbdg  X  p)  »  (getvar  x  (truep  p)) 

getbdgs 

is  like  getbdg  but  calls  trueps  and  returns  a  list  of  values. 

getv.Ks) 

(gttvaKs)  »(rxi..JCn))  • 

(getbdgfs)  y  •(r  xi..jc«  y)) 
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lookupbdgCs)  is  like  getbdgCs)  but  uees  lookup (t)  instead  of  truepfs). 

lookupval(s)  is  like  getval(e)  but  uses  lookup (s)  instead  of  truep(t). 

plug  (plug  X  bl)  returns  expression  x  with  its  variables  fully  instantiated 

from  the  binding  list  bl. 

pluralize  (pluralizs  bl)  turns  a  single  binding  list  into  a  multiple  one  by  putting 

parentheses  round  it. 

•ingularizs  (singular izs  bl)  turns  a  multiple  binding  list  into  a  single  one  by 

taking  the  CAR  of  it. 

§10.4  Tasks  and  the  agenda 

The  following  routines  enable  the  user  to  write  her  own  inference  routines  using  the  scheduler 

architecture: 

kb  (kb  to<T>  Xi .  •  JCn)  invokes  the  meta-level  backward-chainer  trtruep 

to  find  oat  how  to  perform  task  <T>  for  the  given  arguments,  then 
performs  the  task  and  returns  the  results. 

tb  (tb  <T>  X|  • .  JCn)  places  the  task  <T>  on  the  agenda  with  the  given 

arguments. 

scheduler  (sehsdalsr)  starts  the  deliberation-action  process  operating  according 

to  the  flags  sxs eatable,  sxecutsd  and  preferred. 

§10.5  Miscellaneous  routines 

The  following  fu:  ctions  and  commands  operate  only  on  facts  in  the  pr  representation. 

datum  (datum  p)  returns  the  proposition  symbol  for  p. 

pattern  (pattern  d)  returns  the  proposition  for  symbol  d.  Useful  for  unstashing 

facts  without  typing  them  in  verbatim. 

BTsdump  (nrsdump  th  f)  writes  out  the  propositions  in  theory  th  onto  file  f  in 

such  a  way  that  they  can  be  reloaded  using  a  LOAD. 

mrsload  (mrsload  f )  loads  naked  propositions  (i.e.  without  stash  commands) 

from  file  f  into  the  current  theory. 

(mrssave  tht  ...thn  f)  saves  the  propositions  from  the  given  theories 
onto  the  file  f  so  that  they  can  be  reloaded  using  mrsload. 


nrssavs 
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Chapter  11 

Tracing,  cacliing  and  justiflcations 
Sll.l  Tracing 

At  present  the  tracing  mechanism  m  MRS  u  the  only  form  of  debuggbg  other  than  the  LISP* 
provided  utilities,  and  it  is  somewhat  inadequate  to  say  the  least.  Once  the  system  has  chosen  a 
task  to  perform  (usually  Crom  the  agenda),  it  will  be  printed  out  on  the  terminal  if  it  matches  with 
the  pattern  <p>  provided  by  the  user  with  the  command 

(TRACETASK  <p>) . 

Normally  the  pattern  will  be  just  kx  and  the  resulting  output  will  Ust  each  bedisp  (or  any  other 
diep)  task  with  its  arguments  in  a  format  slightly  mere  readable  than  that  provided  by  TRACE. 
(UNTRACETASK  <p>)  turns  off  tracing  for  tasks  matching  <p>.  To  switch  tracing  off  altogether 
just  type  (UNTRACETASK). 

§11.2  Caching 

In  performing  a  proof,  the  system  produces  not  only  the  final  result  but  also  several  intermediate 

facts  which  are  usually  discarded  without  a  second  thought.  This  is  often  shockingly  wasteful _ 

these  results  may  have  to  be  recreated  for  some  later  proof,  or  they  may  even  be  interesting  in 
themselves.  MRS  provides  a  simple  caching  facility  whereby  the  builuin  inference  procedures  (and 
others  if  they  so  desire)  can  stash  specified  classes  of  intermediate  and  final  results. 

To  ^et  this  to  happen,  just  set  the  value  of  the  variable  cache  to  the  name  of  the  theory  you 
would  like  the  results  stashed  in.  See  chapter  7  for  a  description  of  theories.  To  use  the  current 
theory  (the  value  of  theory)  set  cache  to  T.  When  the  time  comes  to  cache  a  result  <p>,  MRS  tries 
to  find  a  caching  routine  <r>  such  that 

(tocache  <p>  <t>) 

is  true.  The  default  is  (cachebystash  <p>)  which  behaves  as  described  above.  The  user  is  free  to 
change  this  as  she  wishes  by  nnstashing  the  default  and  adding  her  own  restricted  «-««“Ni‘ng 
or  new  caching  routines.  Due  to  the  large  number  of  results  produced  by  even  simple  proofs  it  is 
advisable  to  put  them  in  a  separate  theory  which  can  then  be  easily  emptied.  To  turn  off, 

just  type  (SETQ  cache  NIL). 

$11.3  Justifications 

One  of  the  trumpeted  advantages  of  expert  systems  is  their  ability  to  explain  their  own  reasoning. 
They  achieve  this  feat  by  simply  saving,  for  each  deduction  made,  the  premises,  conclusions  and 
inference  rule  used.  This  does  not  of  course  happen  antomaticaUy;  or  rather,  it  does  provided  the 
Jnsbify  fiag  is  non.NlL.  It  should  be  set  to  the  name  of  the  theory  in  which  yon  would  like  the 
justifications  stashed.  If  this  sounds  similar  to  caching,  there’s  more  to  come.  Not  only  does  the 
Justify  flag  cause  saving  of  justifications,  it  also  causes  all  the  resulU  that  caching  would  cache 
to  be  saved  on  the  property  lists  of  specially-generated  proposition  symbols  which  aren’t  attached 
to  any  theory  at  alL  This  is  because  the  justifications  refer  to  these  intermediate  results,  and  they 
must  be  available  for  vby  and  where  (see  below)  to  print  them  out. 

A  justification  is  a  fact  of  the  form 

(just  <eoncl>  <Betbod>  <pzenisei  >  . . .  <prealsen  >) 

where  the  conclusion  and  premises  (which  include  the  rule  used)  are  represented  by  their  corre¬ 
sponding  proposition  symbols,  and  the  method  u  be,  f  e  or  whatever. 
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The  justifications  are  used  by  the  two  commands  why  and  where,  {why  <p>),  if  a  justification 
exists  for  the  proposition,  prints  out  the  inference  method  and  the  premises  from  which  the  proposi¬ 
tion  was  deduced,  (where  <p>)  gives  the  same  informations  for  all  inferences  in  which  <p>)  took 
part  as  a  premise.  The  following  simple  example  illustrates  these  ideas: 

>CS£TQ  Justify  T)  use  current  theory  for  stashing  Justifications 

T 

>theory 

GLOBAL 

> (STASH  ’(Man  Socrates}) 

P285 

> (STASH  ’(IF  (Man  tx)  (Mortal  $x))) 

P286 

>(TRUEP  ’(Mortal  Socrates)) 

((T  .  T)) 

>(why  ’(Mortal  Socrates)) 

P288:  (MORTAL  SOCRATES)  by  BC 
P28S:  (MAN  SOCRATES)  * 

P286:  (IF  (MAN  $X)  (MORTAL  $X)) 

DONE 

> (where  ’(Man  Socrates)) 

P238;  (MORTAL  SOCRATES)  by  BC 
P285:  (MAN  SOCRATES) 

P286;  (IF  (MAN  $X)  (MORTAL  $X)) 

DONE 

>(PRFACTS  ’Just) 

P287:  (JUST  P285  BC) 

F289:  (JUST  P288  BC  P285  P286) 

DONE 
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Chapter  12 

More  general  input  and  output 

The  view  provided  eo  far  of  the  MRS  system  is  that  of  a  baked*  theorem  prover,  taking  facts 
and  queries  in  predicate  calculus  as  input  and  printing  facts  and  binding  lists  as  output.  However, 
since  all  the  output  mechanisms  are  implemented  using  default  rules,  the  user  can  build  any  desired 
interface  for  displaying  facta.  In  addition,  MRS  provides  a  mechanism  for  asking  intelligible  questions 
of  the  user;  thus  it  is  quite  easy  to  build  a  system  in  which  the  user  never  has  to  see  any  predicate 
calculus  at  all.  Also  described  in  this  chapter  are  methods  for  monitoring' the  progress  of  inference 
on  a  display,  and  for  directly  editing  facts  in  the  database. 

§12«1  Asking  questions  of  the  user 

Logic  programming  is  particularly  suited  to  the  implementation  of  consuitatxon  systems  —  systems 
that  operate  in  the  same  mode  as  a  human  consultant,  by  being  informed  of  the  user’s  overall  need 
and  then  askbg  appropriate  questions  to  detennbe  the  necessary  bformation  for  the  solution  of 
the  problem. 

The  backward  chabbg  approach  to  consultation  makes  the  problem  the  initial  goal,  and  works 
back  through  the  rules  until  it  finds  premises  that  can  be  supplied  by  the  user,  rather  like  havbg  an 
extra  database  accessible  via  the  termbal  instead  of  the  lookup  routbe.  We  can  use  the  procedural 
attachment  mechanism  of  MRS  to  implement  this  idea  by  havbg  a  special  subroutbe  aakfs)  perform 
the  function  of  truepfs)  for  the  class  of  facts  that  the  user  is  likely  to  know;  for  example  an 
bteractive  tictactoe  program  might  have 

(totruep  (YourMove  kx)  ask). 

First  of  all  ask  calls  output  on  its  argument  <p>  to  display  it  b  an  understandable  form  (see  next 
section)  and  prints  it  out.  Then  it  exambes  <p>  to  see  if  it  can  be  answered  by  a  yes/no,  which 
is  the  case  if  it  has  no  free  variables.  If  so,  it  asks  the  user  if  the  proposition  is  true  and  returns 
((T  .  T))  or  NIL  accordbgly.  If  not,  it  asks  the  user  to  supply  a  value  for  each  variable  so  as  to 
make  the  proposition  true.  The  routbe  asks,  which  simulates  trusps,  prompts  the  user  for  all  the 
sets  of  values  of  the  variables  which  satisfy  the  query.  In  moat  cases,  unless  truep  is  called  directly 
by  the  user  on  an  askable  query  (which  would  be  somewhat  self*defeatbg),  the  routbe  used  will  be 
asks  rather  than  a^sk#  However,  many  relations  are  really  functional  (i.e.  have  only  one  satisfybg 
bbdbg)  so  the  questions  askbg  for  multiple  values  can  be  a  little  irritatbg.  For  instance,  one  is 
hardly  likely  to  want  to  make  more  than  one  move  at  a  time  b  a  game  of  tictactoe.  The  routbes  can 
accommodate  this  bformation  if  the  user  states  that  the  predicate  bvolved  is  actually  a  function: 

(STASH  ’(Function  YourMove)}. 

This  will  cause  a  sbgle  value  only  to  be  prompted  for. 

Often  a  proposition  will  be  used  as  a  premise  of  more  than  one  rule.  If  it  is  an  askable  one,  this 
may  have  the  annoybg  effect  of  causbg  the  user  to  be  asked  the  same  question  twice  (If  not  more). 
One  solution  is  to  tell  MRS  that  the  class  of  askable  propositions  is  also  to  be  cached  •  ask  won’t 
ask  something  if  it  is  already  m  the  database.  Furthermore,  this  can  be  used  to  produce  a  theory 
contabbg  all  of  the  facts  about  a  particular  user  that  pertab  to  her  problems  which  can  then  easily 
be  stored  permanently  usbg  mrtsava. 

S12.2  Displaying  facts 

All  of  the  MRS  routines  that  prbt  facts  call  output  or  outputs  to  do  so.  The  argument  to  output 
is  a  sbgle  fact,  that  to  outputs  a  list  of  facU.  FacU  are  prbted  out  by  facts,  contents,  the  tracing 
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These  facilities  are  beat  illustrated  by  ninnbg  the  output  demo,  which  may  be  invoked  by 
loading  the  51e  OUTPUT**!.  A  number  of  output  routines  are  implemented  on  the  Symbolics  machine 
only,  since  they  take  advantage  of  its  graphics  capabilities.  These  are  illustrated  in  the  output 
demonstration  for  the  Symbolics  machine. 

§12.3  Monitoring 

Particularly  in  a  system  using  condition* action  rules,  or  one  using  forward  chaining,  one  will  want 
to  monitor  the  changes  made  to  the  database  by  assertions.  For  instance,  a  flight  simulator  will 
want  to  continuously  monitor  such  facts  as  the  amount  of  fuel  remaining  and  the  current  altitude. 
MRS  provides  a  mechanism  for  domg  this  using  demons  (see  chapter  6).  Once  a  proposition  is 
being  monitored,  any  assertion  matching  the  proposition  will  cause  a  function  to  be  invoked  that 
can  either  output  the  assertion  directly  or  call  a  specialised  routine  for  updating  the  appropriate 
display. 

Monitoring  can  be  initiated  for  a  class  of  facts  matching  <p>  using  the  command  (monitor 
<p>).  The  command  monitors  takes  a  list  of  propositions  to  be  monitored.  The  effects  are  as 
follows.  Firstly,  forward  chaining  is  asserted  for  the  proposition  so  that  the  monitor  demon  will 
fire: 


(toassert  <p>  fc). 

Secondly,  the  demon  is  created: 

(IF  <p>  (runntbla  (monitor**hook  <p>)}). 

Now  we  have  to  decide  if  we’re  going  to  monitor  the  fact  by  just  printing  it  out,  or  by  maintaining 
some  display  (such  as  a  needle  gauge  or  a  digital  readout)  for  it.  To  discover  this,  trtruep  is  called 
on  a  goal  of  the  form 

(tomonitor  <p>  <m«thod>)  • 

It  is  important  to  remember  that  the  call  to  monitor  is  intended  to  initiate  monitoring  for  its 
argument,  rather  than  actually  perform  it.  Thus  the  tomonitor  method,  which  will  of  course  be 
a  LISP  routine,  set  up  whatever  display  window  or  file  may  be  needed  for  monitoring  the  facts. 
monitor**hook  is  the  function  that  gets  the  facts  displayed,  and  the  tomonitor  method  must  also 
therefore  provide  some  information  for  monitor^hook  as  to  exactly  how  and  where  to  display  them. 
The  convention  adopted  is  that  it  should  return  a  CONSed  pair  whose  CAR  is  the  name  of  the 
function  which  will  do  the  displaying,  and  whose  CDR  Indicates  where  these  facts  are  to  be  displayed 
(it  might  be  the  name  of  a  file,  or  a  pointer  to  a  window).  The  monitor  function  takes  this  returned 
pair  and  uses  it  to  create  a  fact  in  the  database  of  the  form 

(mdisplay  <p>  <di8play  function>  <display  argufflent>). 

Now,  whenever  a  fact  matching  <p>  is  asserted,  monitor-book  will  find  the  mdisplay  fact  for  it 
and  call  the  display  function  with  two  arguments:  the  fact  and  the  display  argument.  Multiple 
displays  for  a  fact  can  be  handled  because  monitor-hook  finds  all  the  applicable  mdisplay  facts. 

Clearly,  the  desired  default  display  function  must  be  output.  Since  output  doesn’t  require  the 
display  argument,  our  default  tomonitor  method  will  just  be  a  function  that  returns  (output  . 
NIL),  i.e. 


(tomonitor  kp  (lambda  (p)  ’(output))} 


4 


[ : 


54  The  Complcat  Guide  to  MRS 

facility,  the  justiScation  routined  vhy  and  where,  and  by  eek.  Moreover,  the  user  can  invoke  output 
directly  for  display  and  debugging  purposes. 

The  output  (a)  routines  work  by  calling  trtruep  (the  meta-level  theorem  prover)  on  the  goal 
(tooutput(s)  <p>  <a>) 

where  <p>  is  the  fact(8)  to  be  printed.  The  returned  output  method  <ffi>  will  be  called  on  the 
fact(3);  thus  the  user  can  specify  any  desired  output  routine  by  stashing  w  tooutputfs)  fact  for  it. 
The  output  routines  can  do  anything  the  user  wishes,  from  printing  charts  and  trees  to  moving  dials 
or  beepbg  Morse  code.  Several  useful  routines  are  provided,  and  described  below. 

The  default  tooutput  method  is  pnl-output  (pnl  standing  for  pseudo-natural  language).  The 
default  tooutput s  method  is  prop-outputs,  which  prints  the  facts  verbatim,  preceded  by  their 
associated  proposition  symbol  (as  in  the  output  from  the  facts  routine).  Sometimes,  for  instance 
during  debugging,  one  may  want  to  print  out  facts  in  this  default  format  instead  of  whatever  fancy 
format  one  has  defined  for  them.  The  command  (prf  acts  <t>  <lsvel>)  (the  arguments  are  the 
same  as  those  of  facts)  does  just  this. 

12.2.1  Pseudo-natural  language  output 

The  pnl -output  routine  mentioned  above  is  designed  to  provide  a  form  of  translation  from 
predicate  calculus  into  English  (or  whatever)  using  templates.  A  template  is  essentially  a  sentence 
with  holes  that  are  to  be  plugged  with  appropriate  values.  For  instance,  we  would  specify  the 
template  for  YouxMove  by  stashing 

(Template  (YourHovs  4x}  (Youx  next  move  is  going  to  be  Jtx)). 

When  output  is  called  on  a  proposition  p,  it  tries  to  find  a  template  whose  left-hand  side  unifies 
with  p  (note  that  this  will  be  a  meta-level  unification)  and  when  successful  applies  the  binding  list 
to  the  right-hand  side  and  returns  the  result.  This  process  b  actually  recursive;  pnl-output  caUs 
itself  on  each  binding  of  a  template  variable  before  plugging  it  into  the  sentence.  Thus  suppose  we 
had  a  case  in  the  tictactoe  game  wheie  the  program  could  predict  where  the  user  was  going  to  move 
and  wanted  to  show  off.  Recalling  that  the  moves  are  represented  by  the  digits  1  to  9,  we  could  add 

(Template  1  (in  the  top  left  corner)} 

•  e  e 

(Template  5  (in  the  center)) 

(Template  9  (In  the  bottom  right  comer)}. 

12.2.2  Other  output  routines 

Several  output  routines  are  provided  with  MRS  for  dbplaying  information  in  various  formats. 
Each  of  the  following  functions  takes  a  Ibt  of  facts  as  its  only  argument: 

indent-tree-outputs  Prints  out  the  binary  relation  described  by  the  facts  in  the  Ibt  as  an 
indented  tree,  if  possible. 

■imple-bar- outputs  Takes  a  Ibt  of  facts  describing  a  function  with  numeric  range,  and  prints 
out  a  simple  bar  chart  containing  the  information. 

table-outputs  Sorts  the  Ibt  of  facts  by  predicate  and  arity,  and  prints  out  a  table  for 
each  relation. 


e 
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This  has  all  been  very  confusbg,  no  doubt,  but  perhaps  an  example  will  help.  The  following 
transcript  comes  from  the  output  facility  demo,  and  shows  how  to  implement  a  history  61e  of 
database  assertions  using  monitoring  (while  this  isn’t  the  most  exciting  use  of  monitoring,  it  is,  at 
least,  implementable  in  all  versions  of  MRS): 

MONITORING  for  dumb  terainala  -  count  up  to  ten-» 

{STASH  (QUOTE  (IP  (AND  (NEAR-TEN  $X)  (<  $X  10)  (♦  $X  1  $Y))  (NEAR-TEN  $Y)))) 
(TRSTASH  (QUOTE  (TEKPUTE  (NEAR-TEN  AX)  («  is  near  ten)))) 

(MONITOR  (QUOTE  (NEAR-TEN  $X))) 

$X  it  near  ten 

(TRSTASH  (QUOTE  (TOMONITOR  (NEAR-TEN  AX)  HISTORY-MONITOR))) 

(MONITOR  (QUOTE  (NEAR-TEN  $X))) 

(DEFUN  HISTOfeY-MONITOR  (P  AOPTIONAL  (FILE  NIL)) 

(COND  ({NULL  FILE) 

(UT  ((STREAM  (OPEN  (QUOTE  OUTPUT-DEMO)  (QUOTE  OUT)))) 
(HISTORY-MONITOR  P  STREAM) 

(CONS  (QUOTE  HISTORY-MONITOR)  STREAM))) 

((EQ  P  (QUOTE  KILL))  (CLOSE  FILE)) 

(T  (PRINC  P  FILE)  (TERPRI  FILE)))) 


-» 

(ASSERT  (QUOTE  (NE'^-TEN  3))) 

3  is  near  ten 

4  is  near  te^ . 

6  is  near  ten 

6  is  nuar  ten  * 

7  is  near  ten 

8  is  near  ten 
0  is  near  ten 
10  is  near  ten 

(UNMONITOR  (QUOTE  (NEAR-TEN  $X))) 

(LET  ((IN  (OPEN  (QUOTE  OUTPUT-DEMO)  (QUOTE  IN)))) 

(PRINC  (READ  IN))  (CLOSE  IN)) 

(NEAR-TEN  $X) 

First  we  stash  a  simple  rule  for  counting  up  to  ten,  and  a  template  for  printing  its  status.  Then 
we  call  monitor  to  establish  default  monitoring  for  NEAR-TEN,  which  will  display  it  using  output. 
Then  we  add  an  additional  monitor  using  the  function  history-monitor,  which  will  print  the  facts 
directly  on  a  file.  Using  an  optional  argument,  history-monitor  can  act  as  both  the  set-up  and 
the  display  function.  Forward  chaining  for  NEAR-TEN  is  turned  on  by  monitor,  so  when  we  assert 
(NEAR-TEN  3)  it  counts  up  to  ten,  and  each  new  fact  is  both  displayed  on  the  terminal  and  printed 
on  the  file.  At  the  end,  we  call  unmonitor  on  the  fact  to  terminate  monitoring,  and  check  the  output 
file  to  see  that  something  was  in  fact  printed  on  it. 
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§12.4  Editing 

At  present  MRS  provides  for  direct  database  editing  only  on  the  Symbolics  Lisp  Machinei  although 
it  is  anticipated  that  this  will  soon  be  extended  to  the  other  implementations.  There  are  two  editing 
commands: 

f  acta-edit  (f  acts*«dit  <t>  <a>)  finds  all  facts  containing  the  tcim  <t>  (up 

to  the  optional  level  <n>),  and  calls  the  appropriate  toodit  method  for 
those  facts. 

coatentg-edit  (coat eat t*edit  <th>)  finds  and  edits  all  facts  in  the  theory  <th> 

(which  defaults  to  the  value  of  theory  if  omitted). 

It  is  the  job  of  the  editing  function  to  invoke  the  editing  environment,  and  to  return  a  list  of  all 
the  fwts  in  their  new  form,  including  those  remaining  unchanged;  if  none  are  changed,  the  editing 
function  may  return  NIL. 

It  is  also  possible  to  do  editing  by  using  an  output  routine  which  retains  control,  allows  the  user 
to  modify  the  facts  displayed,  and  updates  the  database  before  returning.  Thus  the  user  can  enter 
information  by  merely  mouse*8etting  a  dial  or  gauge,  as  well  as  typing  facts  explicitly  in  an  editor. 


c 
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§A.l  Answers  to  problems  from  chapter  2 


1.  (Horse  Dobbin) 

Dobbin  is  a  Horse. 

2.  (Hcffiber  Dobbin  Borses) 

Dobbin  is  a  member  of  the  class  of  horses. 

3.  (NOT  (Horse  Dobbin)) 

Dobbin  is  not  a  horse. 

4.  (OR  (Horse  Dobbin)  (Donkey  Dobbin)) 

Dobbin  is  a  Horse  or  a  donkey. 

5.  (IF  (Horse  Dobbin)  (MamnaX  Dobbin)) 

If  Dobbin  is  a  horse  then  he  is  a  mammaL 

6.  (IF  (Horse  $x)  (Mamnal  $x)) 

All  horses  are  man  mals. 

7.  (IF  (OR  (Horse  $x)  (Cow  $x))  (FourLtgged  Jx)) 

All  horses  and  cows  ere  four>legged. 

8.  (AND  (Maxaaal  $x)  (FonrLegged  $x)) 

Everything  is  a  four-legged  mammaL 

9.  (IF  (NOT  (Horse  Dobbin))  (Dutchnan  Emintrude) ) 

If  Dobbin  b  not  a  horse  then  Ermintrude  b  a  Dutchman. 

10.  (IF  (NOT  (Cow  $x))  (Brown  Dobbin)) 

If  there  b  anything  that  bn’t  a  cow  then  Dobbin  b  brown. 

11.  (IF  (AND  (Horse  $x)  (NOT  (Maaaal  $x)))  (Cow  $x)) 

Every  horse  that  bn’t  a  mammal  b  a  cow. 

12.  (IF  (OR  (•  $x  Dobbin)  (•■  $x  Tonto})  (Horse  $x)) 

Dobbin  and  Tonto  are  horses. 

13.  (IF  (AND  (“  $x  Dobbin)  (■  $x  Tonto))  (Horse  $x)) 

Everything  which  b  both  Dobbin  and  Tonto  b  a  horse. 

14.  (IF  (AND  (Maaaal  $x)  (NOT  (-  $x  Dobbin)))  (NOT  (Horse  $x)) 

Dobbin  b  the  only  mammal  that’s  a  horse. 

15.  (IP  (AIJD  (Horse  $x)  (NOT  (-  tx  $y)))  (NOT  (Horse  ty)) 

There  b  at  most  one  horse.  (Sometimes  propositions  are  difficult  to  translate  directly  —  it  b 
better  then  to  construct  a  universe  that  b  consbtent  with  them  and  describe  that  universe.) 

16.  (NOT  (Member  $x  $x)) 

Nothing  b  a  member  of  itself. 

17.  (IF  (AND  (Horse  $x)  (Brown  $x))  (Brown  (TailOf  $x))) 

Brown  hones  have  brown  taib. 

18.  All  dogs  bark  at  their  neighbours’  dogs. 

(IF  (AND  (Dog  $d)  (Neighbour  $d  $n)  (BelongsTo  $nd  $n)  (Dog  $nd)) 

(BarksAt  $d  $nd)) 

19.  No  real  numbers  are  integer. 

(IF  (RealNuaber  $x}  (NOT  (Integer  $x))) 

20.  Horses  who  hate  dogs  like  ire  cream. 
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(IF  (AN’D  (Horse  $h)  (Hates  $h  Dogs)) 

(Likes  $h  IceCreaa)) 

21.  Giraffes  have  longer  necks  than  Dobbin. 

(IF  (Giraffe  $g)  (Longer  (HeckQf  $g)  (HeckOf  Dobbin))) 

22.  An-An  is  the  only  male  panda  in  London. 

(IF  (AND  (Hale  $x)  (Panda  $x)  (In  lx  London)) 

(-  $x  An-An)) 

23.  Zero  is  an  integer. 

(Integer  0) 

24.  The  fractional  part  of  an  integer  is  sero. 

(IF  (Integer  $x)  (FractionalPart  $x  0)} 

25.  The  product  of  two  real  numbers  is  a  real  nnmber. 

(IF  (AND  (RealNunber  )x)  (RealNuaber  ly)  (•  lx  ly  $z)) 
(RealNuaber  lx)} 

26.  The  product  of  a  positive  bteger  and  its  inverse  is  unity. 

(IF  (AliD  (Integer  lx)  (>  |x  0)  (Quotient  1  |x  linv)) 

(•  lx  linv  1)) 

27.  Zero  is  an  additive  identity. 

(♦  lx  0  lx) 

28.  The  product  of  two  real  numbers  is  never  an  imaginary  number. 

(IF  (AND  (RealNumber  |x)  (RealNunber  ly)  (•  lx  ly  lx)) 

(NOT  (laaginary  |z))) 

29.  All  numbers  are  either  real  or  imaginary  or  both. 

(IF  (Nximber  lx)  (OR  (RealNumber  lx)  (Imaginary  lx))) 

30.  All  Englishmen,  Scotsmen  and  Welshmen  are  British. 

(IF  (AND  (EnglishPerson  |m)  (Scot sPer son  |m)  (VelshPerson  la)) 
(BritishPerson  |m)) 
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§A.2  Answers  to  problems  from  chapter  3 

In  the  following  answers  we  will  rename  variables  in  those  cases  where  it  is  necessary  as  $1,  $2  etc., 
corresponding  to  the  variables  in  the  second  proposition  in  left  to  right  order  of  appearance. 

1.  (p  $a)  and  ($r  x). 

(($r  .  p)  ($a  .  x)) 

2.  (p  $a)  and  ($a  q). 

(($a  .  q)  ($1  .  p)) 

3.  (p  $a  c)  and  (p  $y}. 

No  unifier  possible  —  different  numbers  of  arguments. 

4.  (q  (f  $c))  and  (q  $d). 

(($d  .  (f  $c))) 

5.  (r  (g  $c))  and  (r  3c). 

((31  .  (g  3c))) 

6.  (r  3x  (h  3x))  and  (r  3b  3b). 

No  possible  unifier  —  infinite  substitution  process. 

7.  (p  3a  (g  3a)  (h  3a))  and  (p  (g  3b)  (g  .  3c)  (3d  .  3c)). 

((3a  .  (g  3b))  (3c  .  ((g  3b)))  (3d  .  h)) 

8.  (q  3a)  and  (3r  .  38). 

((3r  .  a)  (3s  .  (3a))) 

<  9.  (r  3b  .  3b)  and  (r  3c  a). 

((3b  .  (a))  (3c  .  (a))) 
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§A.3  Answers  to  problems  from  chapter  5 

1.  Tictactoe  solution. 

; Strategy  rules  *  last  has  prscedtscs  because  of  reverse  search  order 

(IF  (AKD  (Square  $aoTe)  (unknovn  (On  $any8ide  $move)}) 

(BestHove  $0X  $sove)) 

(IF  (A!7D  (OppositcSide  $0X  (opponent)  (IinsiddiateVin  (opponent  (move)) 
(BestMove  (OX  (move)) 

(IF  (ImmedlateVin  (OX  (move)  (BestMove  (OX  (move)) 

; Rules  for  deciding  vhen  an  immediate  vin  is  available 

(IF  (Alio  (VinLine  (A  (B  (C) 

(On  (OX  (A) 

(On  (OX  (B) 

(unknown  (On  (X  (C))) 

(ImmediateVin  (OX  (C)) 

(IF  (AllD  (VinLine  (A  (B  (C) 

(On  (OX  (A) 

(On  (OX  (C) 

(unknown  (On  (X  (B))) 

(ImmediateVin  (OX  (B)) 

(IF  (AND  (VinLine  (A  (B  (C) 

(On  (OX  (C) 

(On  (OX  (B) 

(unknown  (On  (X  (A))) 

(ImmediateVin  (OX  (A)) 

(OppositeSide  0  X) 

(OppositeSide  X  0) 

; Squares  are  listed  in  this  order  so  the  system  will 

;pick  the  generally  better  squares  when  it  has  no  other  clue. 

(Square  2) 

(Square  4) 

(Square  6) 

(Square  8) 

(Square  1) 

(Square  3) 

(Square  7) 

(Square  9) 

(Square  5) 


(VinLine  123) 
(VinLine  159) 
(VinLine  1  4  7) 
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(VinLine  753) 
(VinLine  456) 
(WinLine  789) 
(VinLina  2  5  8) 
(VinLine  369) 


64  The  Compleat  Guide  to  MRS 


2.  Chess  solution. 

This  problem  is  not  conceptually  difBcult  but  is  good  practice  for  organizing  a  large,  complex 
set  of  rules.  It  is  important  to  think  carefully  about  what  predicates  to  define  so  that  each  has  a 
clear  meaning  to  you  and  also  is  a  useful  building  block  for  the  expression  of  the  higher  level  rules. 


The  following  rules  define  the  LegalMove  predicate  which  tests 
or  generates  legal  moves  in  chess.  Ths  argtiments  of  LegalMove 
are  as  follows: 

$bw  -  The  color  of  the  side  whose  turn  it  is  to  move. 

Valuss  axe  Black  and  White. 

$coli$row  *  The  column  and  row  coords  of  ths  origin  square. 

White’s  QRl  is  dssignated  1,1. 

$newcol,$newrow  -  Ths  coords  of  ths  dsstination  squars. 

$flag  Indicatss  ths  move  class: 

0  is  a  normal  move 
P  is  an  en  passant  capture 
C  is  a  castling  movs. 

N/B/R/Q  is  ths  new  piece  for  a  queening  move 


;  Rules  establishing  the  various  classes  of  moves  and  their  legality  ; 


;Condition  for  a  normal  move  to  be  legal  (king  moves  done  separately): 
:  not  already  in  check,  and  no  discovered  check 

(IF  (AND  (Unknown  (XnCheck  $bw)) 

(Move  $bw  Icol  trow  tnewcol  tnewrow) 

(On  Ibw  tpiece  $coI  trow) 

(Unknown  (•  tpisce  K)) 

(Unprovable  (OisccveredCheck  tbw  tcol  trow  tnewcol  tnewrow)}) 
(LegalMove  tbw  tool  trow  tnewcol  tnewrow  0)) 

:If  castling  is  possible  it’s  legal 

(IF  (CastlingMove  tbw  tside) 

(LegalMove  tbw  Castles  tsids  0  0  C)) 

; Condition  for  a  king  move  to  be  safe 

(IF  (AND  (On  tbw  K  tcol  trow) 

(Move  tbw  tcol  trow  tnewcol  tnewrow) 

(Opponent  tbw  twb) 

(Unprovable  (Attacking  twb  tnewcol  tnewrow)) 

(-  tnewcol  tcol  tcv) 
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(“  taewrow  $row  trv) 

(Unprovabl* 

(AKD  (AttacksAlons  $plec«  $pcol  (prow  (col  (row  (cv  (rv) 
(MultiPieco  (piece)))} 

(LegalMove  (bw  (col  (row  (newcol  (newrow  0)) 

: Condition  for  a  aove  to  get  us  out  of  check 
J  (other  than  a  king  nova,  which  la  tested  lor  safety  already) 

;  This  can  only  work  11  there  is  only  one  checking  piece,  which  is 
:  on  (pcol,(prow 

(IF  (AND  (InCheck  (bw) 

(Opponent  (bw  (wb) 

(On  (bw  K  (kcol  (krow) 

(SETOF  ($pc  (pr) 

(Attacks  (wb  (p  (pe  (pr  (kcol  (krow) 

(((pcol  (prow))) 

(EseapesCheck  (pcol  (prow  (bw  (col  (row  (newcol  (newrow  (flag)) 
(LegalMove  (bw  (col  (row  (newcol  (newrow  (flag)) 

: Condition  for  a  pawn  aove  to  be  legal 

(IF  (AND  (Unknown  (InCheck  (bw)} 

(PawnMove  (bw  (col  (row  (newcol  (newrow  (qpiece) 

(Unprovable  (DiaeoveredCheek  (bw  (col  (row  (newcol  (newrow))) 
(LegalMove  (bw  (cal  (row  (newcol  (newrow  (qpiece)} 

: Condition  for  an  en  passant  aove  to  be  legal 

(IF  (AND  (Unknown  (InCheck  (bw)) 

(EnPaaaantMove  (bw  (cel  (row  (newcol  (newrow  P) 

(Unprovable  (DiscoveredCheck  (bw  (col  (row  (newcol  (newrow)) 
(Unprovable  (Pinned  (bw  (newcol  (row  (pcol  (prow))} 

(LegalMove  (bw  (col  (row  (newcol  (newrow  P)) 


Conditions  for  various  types  of  aoves  to  escape  check,  either  by 
taking  the  cheeking  piece  or  by  interposing 


(IF  (AND  (PawnMove  (bw  (cel  (row  (col  (newrow  (qpiece) 

(On  (bw  K  (kcol  (krow) 

(Between  (col  (newrow  (kcol  (krow  (pcol  (prow) 

(Unprovable  (DiscoveredCheck  (bw  (cel  (row  (eel  (newrow))) 
(EseapesCheck  (pcol  (prow  (bw  (col  (row  (col  (newrow  (flag)) 

(IF  (AND  (PawnMove  (bw  (col  (row  (pcol  (prow  (<ipiece) 

(Unprovable  (DiscoveredCheck  (bw  (col  (row  (col  (newrow))) 
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(EacapesCheck  $pcol  $protf  $bw  $col  $rov  $pcol  $prow  Sqplece)) 

(IF  (AND  (EnPastimtHove  $bw  $col  $prov  $pcol  $nevrow  P) 

(Unprovablo  (DiacoveredChcck  $bw  $col  $prow  $pcol  $newrow)) 
(Unprovable  (Pinned  $bv  $pcol  $prow  $pinc  $pipx)}} 
(EacapesCheck  $peol  $protf  $bv  $col  Iprow  $pcol  Inewrow  P)) 

(IF  (AND  (EnPaaaantMove  $bw  $col  $rov  $nawcol  $ntwrow  P) 

(On  $bw  K  $kcol  $krow) 

(Between  $newcol  Snewxow  Ikcol  $krow  $pcol  $prow) 

(Unprovable  (DitcoveredCheck  $bw  tcol  $row  $newcol  Inewrow)}} 
(EacapesCheck  $pcol  $prow  $bw  $col  $row  $newcol  $newrow  P)} 

(IF  (AND  (Move  $bw  $col  $rov  $newcol  $newrow) 

(UNKNOWN  (On  |bw  X  $col  $row)} 

(Unprovable  (DiscoveredCheck  $bw  $col  $row  $newcol  $newrow)) 
(On  $bw  K  Ikcol  $kxow) 

(OR  (Between  Inewcol  Inewrow  Ikcol  Ikrow  Ipcol  Iprow) 

(AND  (•  Inewcol  Ipcol)  ("  Inewrow  Iprow}))) 

(EacapesCheck  Ipcol  Iprow  Ibw  Icol  Irow  Inewcol  Inewrow  0}) 


Conditions  for  legal  castling:  unaoved  king  and  rook,  not  in  check, 
no  intervening  pieces,  no  intervening  checks. 


(IF  (AND  (UnaovedX  Ibw) 

(CastlingSide  Iside) 

(Unknown  (InCheck  Ibw)) 

(UnnovedE  |bw  Iside) 

(Opponent  Ibw  |wb) 

(Unprovable  (AND  (CastlingMoveSquare  Ibw  Iside  Icol  Irow) 
(On  lanyside  lanypiece  Icol  Irow)}) 
(Unprovable  (AND  (CastlingCheckSquare  Ibw  Iside  Icol  Irow) 
(Attacking  |wb  Icol  Irow))}) 

(CastlingMove  Ibw  Iside)) 


;  Conditions  for  pawn  moves  other  than  en  passant  ; 


(IF  (AND  (On  Ibw  P  Icol  Irow) 

(Direction  Ibw  loneforward) 

(Opponent  Ibw  Iwb) 

(PawnRank  |wb  Iqrank) 

(OR  (AND  (*  Icol  Inewcol) 

(♦  Irow  loneforward  Inextrow) 

(Unknown  (On  lanyside  lanypiece  Icol  Inextrow)) 
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(OR  (-  $nextrow  Snewrovr) 

(AMD  (PsvnRank  $bvr  $rotf) 

(<f  $nextrotf  $oneforvaxd  Snevrov) 

(Unknown 

(On  $anytidQ2  $anypiece2  $col  $newrow))))) 
(AND  (Attacks  $btf  P  $col  $row  Inswcol  $n«wrow) 

(On  $wb  $anypittct3  $nevcol  $newrow))} 

(OR  (AND  (*  $z'ow  $qrank) 

(QueeningPiaca  tqplaca)) 

(AND  (Unknown  (■  Irow  Iqrank)) 

(-  $qpiaca  0)))) 

(PawnHova  $bw  $col  $row  $nawcol  $nawrow  $qpiaca)} 


Condition  lor  a  normal  nova  other  than  pawn  novas  ; 


(IF  (AND  (On  $bw  $piaca  $cl  $rl)  (Unknown  (■  $piaca  P)) 
(Attacks  $bw  $piaca  $cl  $rl  $c2  $r2) 

(Unknown  (On  $bw  $anypiaca  $c2  $r2))) 

(Mova  $bw  $cl  $rl  $c2  $r2)) 


Condition  for  an  passant  nova 


(IF  (AND  (EnPassantRank  $btf  $row) 

(On  $bw  $eol  $row) 

(PraviousMova  $wb  $pcol  $prow  $pcol  $row  0) 
(PawnRank  $wb  $prow) 

(On  $wb  P  $pcol  $rov) 

(Attacks  $bw  P  $col  $row  $pcol  $nawrow)) 
(EnPassantMova  $bv  $col  $row  $nawcol  $nawrow  P)} 


Rulas  for  datamining  discovarad  chacks 


(IF  (AND  (Pinned  $bv  $col  $row  $pcol  Iprow) 

(-  Snawcol  $col  Icvl) 

(•  $nawrow  $row  $rvl) 

(**  $pcol  $col  $cv2) 

(-  $prow  Irow  $rv2) 

(Unprovabla  (Parallel  Icvl  |rvl  |cv2  Irv2))) 

(DiscoveradChack  Ibw  Icol  Irow  Inawcol  Inawrow)? 

;Condition  for  a  piece  to  ba  ’pinned*,  l.a.  unranovabla  by  Ibw 
:  Cpcol  ,prow]  »»»»»  [col ,  row]  [nrxtcol  .naxtrow]  »»»»» [kcol  ,krow] 
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(IF  (AND  (On  $bw  K  $kcol  $kxov) 

(UnitVector  $col  $row  $kcol  Skxow  $c7  $rv) 

(♦  $col  $cv  $nextcol)  (♦  $row  $rv  Incxtrow) 

(Route  $nextcol  Snoxtrov  $kcol  $krov  $cv  $rv) 

(Opponent  $bw  $vb) 

(AtteckeAlong  $tfb  $piece  $pcol  $prow  $col  $roy  $cv  $rv) 
(HultiFlece  $piece)) 

(Pinned  $b«  $col  $row  $pcol  $prow)) 


;  Rules  to  determine  when  pieces  ere  ettecking  squaree  ; 


:Definition8  of  different  specificities  of  attacks 

(IF  (AttacksAlong  $bw  $p  $cl  $ri  $c2  $r2  $cv  $rv} 

(Attacks  $bw  $p  $cl  $rl  $c2  $r2}) 

(IF  (Attacks  $btf  $p  $ci  $rl  $c2  $r2) 

(Attacking  $btf  $c2  $r2)) 

: Condition  for  attacking  a  ’neighbouring*  square  with  vector  $cv  $rv 

(IF  (AND  (On  $bw  $piece  $col  $row) 

(MoveVector  $piece  $bw  lev  Irv) 

(NextTo  Icol  Irow  lev  |rv  Inewcol  Inewrow)) 

(AttacksDirectly  Ibw  Ipiece  Icol  Irow  Inewcol  Inewrow  lev  Irv)) 

:Ba8e  case  for  attacking  a  ’distant’  square 

(IF  (AND  (AttacksDirectly  |bw  Ipiece  Icol  Irow  Inewcol  Inewrow  lev  |rv) 
(Unknown  (MultiPiece  Ipiece))) 

(AttacksAlong  |bw  Ipiece  Icol  Irow  Inewcol  Inewrow  lev  Irv)) 

:Condition  for  a  piece  to  attack  a  ’distant’  square  with  vector  ^cv  Irv 

(IF  (AND  (On  |bw  Ipiece  Icol  Irow) 

(MultiPiece  Ipiece) 

(AttacksDirectly  Ibw  Ipiece  Icol  Irow  |col2  |row2  lev  Irv) 
(Route  |col2  |row2  Inewcol  Inewrow  lev  Irv)) 

(AttacksAlong  Ibw  Ipiece  Icol  Irow  Inewcol  Inewrow  lev  Irv)) 


Route  sees  if  there  is  a  clear  path  from  one 
square  to  another  along  a  given  vector. 


(Route  Icol  Irow  Icol  Irow  lev  Irv)) 
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(IF  (AND  (Unknown  (On  $Rnyoid«  $anypicc®  $col  $row)) 
(Rout®  $col2  $row2  $netfcoI  $ncwrow  $cv  $rv)) 
(Rout®  $col  $row  $nevcol  Snevrow  $cv  $rv)) 


Predicate®  for  handling  vector  arithmetic 


;  NextTo  give®  the  next  equare  to  $coI  $row  alon^  vector  $cv  $rv 

(IF  (AND 

('*>  $col  $cv  Snewcol) 

(<  $nevcol  9)  (>  $nevcoI  0) 

(+  $row  $rv  Jnewrow) 

(<  $newrow  9)  (>  $newrow  0)) 

(NextTo  $col  $row  $cv  $rv  Snewcol  Snewrow)) 

;Definition  of  parallel  vectors 

(IF  (IS  (-  (•  $cvl  $rv2)  (•  $cv2  $rvl))  0) 

(Parallel  $cvl  $rvl  $cv2  $rv2)) 

;UnitVector  finds  the  appropriate  move  vector  to  get  between  two  square® 

(IF  (AND  (-  $col2  Scoll  $acv} 

(-  $row2  $rowl  $fflrv) 

(Sign  $mcv  $cv) 

(Sign  $nirv  $rv)) 

(UnitVector  $coll  $rowl  $col2  $row2  $cv  $rv)) 

(IF  (>  $x  0)  (Sign  $x  D) 

(IF  (<  $x  0)  (Sign  $x  -D) 

(IF  (-  $x  0)  (Sign  $x  0)) 

;Between  sees  if  a  square  x  is  between  two  others  y.x 

(IF  (AND  (-  $zc  $xc  $cvl) 

(-  $zr  $xr  Srvl) 

(-  $yc  $xc  $cv2) 

(•  lyr  $xr  $rv2) 

(Parallel  $cvl  $rvl  $cv2  $rv2) 

(IS  (♦  (*  $cvl  $cv2)  (•  $rvl  $rv2))  Sdotprod) 

(<  Sdotprod  0}) 

(Between  $xc  $xr  $yc  $yx  $zc  $zr)) 


Data  tables  for  castling,  move  vectors,  piece  classes 
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(CastlingSida  Kings^aide) 

(CastllngSide  Queens^aida) 

(Opponent  Whita  Black) 

(Opponent  Black  Vhita) 

(CaatlingCheckSquart  Vhito  Kinga-sida  7  1) 
(CaatlingChackSquara  Vblta  Klnga-aida  6  1) 
(CaatlingCbackSquara  Vkita  Quaaua-aida  3  1) 
(CaatlingCbackSquara  Vhita  Quaana**8ida  4  1) 
(CaatlingChackSquara  Black  Kinga-sida  7  8} 
(CaatlingChackSquara  Black  Kinga-aida  6  8) 
(CaatlisgChackSquara  Black  Quoana-aida  3  8) 
(CaatlingCbackSquara  Black  Quaana-aida  4  8) 
(CaatlingMoveSquara  Vbita  Klnga*aida  7  1} 
(CaatlingMoveSquara  Vbita  Kinga-aida  6  1) 
(CaatlingMoveSquara  Vbita  Quaena-aida  2  1) 
(CaatlingMoveSquara  Vbita  Quaana-aida  3  1} 
(CaatlingMoveSquara  Vbita  Quaena-aida  4  1} 
(CaatlingMoveSquara  Black  Kinga-aida  7  8) 
(CaatlingMoveSquara  Black  Kinga-aida  6  8) 
(CaatlingMoveSquara  Black  Quaana-aida  2  8) 
(CaatlingMoveSquara  Black  Queena-aida  3  8) 
(CaatlingMoveSquara  Black  Quaana-aida  4  8) 
(Direction  Vbita  1} 

(Direction  Black  -1} 

(PamRaiUc  Vbita  2) 

(Pa\mRank  Black  7} 

(EnPasaantRank  Vbita  5) 

(EnPaaaantRank  Black  4) 

(QuaeningPieca  N) 

(QueaningPieca  B) 

(QuaeningPieca  R) 

(QuaeningPieca  Q) 

(MultiPieca  B) 

(MultiPieca  R) 

(MultiPieca  Q) 

(MovaVactor  P  Vbita  1  1) 

(KovaVactor  P  Vbita  -1  1) 

(MovaVactor  P  Black  1  -1) 

(MovaVactor  P  Black  -1  -1) 

(MovaVactor  N  lanyaida  1  2) 

(MovaVactor  N  $anyaida  2  1) 

(MovaVactor  K  lanyaida  2  -1) 

(MovaVactor  N  lanyaida  1  -2) 

(MovaVactor  N  lanyaida  -1  -2) 

(MovaVactor  N  lanyaida  -2  -i) 

(MovaVactor  N  lanyaida  -2  1) 

(MovaVactor  N  lanyaida  -i  2) 
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(MovcVcctor  B 
(KoveVcctor  B 
(MoveVector  B 
(MoveVector  B 
(MoveVector  R 
(MoveVector  B 
(MoveVector  R 
(MoveVector  R 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  Q 
(MoveVector  K 
(MoveVector  K 
(MoveVector  K 
(MoveVector  K 
(MoveVector  K 
(MoveVector  K 
(MoveVector  K 
(MoveVector  K 


Saxxysido  1  1) 
Sanyside  1  -1) 
Sanyeide  -1  -1) 
Saayeide  -1  1) 
Saxxyside  1  0) 
$anyside  0  1) 
Sanyside  -1  0) 
Stnyeide  0  -1} 
Sanyside  1  1) 
Sanyside  1  -1) 
$anyeide  -1  -1) 
$aBy«ide  -1  1) 
ianyside  1  0) 
$a&yside  0  1) 
Sanyeide  -1  0) 
$anyside  0  -1} 
tanyside  1  1) 
Sanyside  1  -1) 
$aay*ide  -1  -I) 
$anytide  -1  1} 
$axiyside  1  0) 
$anyside  0  1) 
$any8ide  *1  0) 
Sanytide  0  **1) 
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3.  Geometry  solution. 

The  ontology  for  geometry  is  fairly  well-known  — •  points,  lines,  angles  and  circles  cover  most 
things.  Points  are  identiSed  by  constant  symbols  just  as  in  real  life.  Lines  and  angles  can  be 
represented  by  terms  with  function  symbols  Lino  and  Anglo;  for  example,  the  line  segment  AS  wU 
be  called  (Line  A  B).  Circles  could  be  represented  by  a  term  with  function  symbol  Circle  with  the 
points  on  the  circle  as  arguments,  but  for  our  purposes,  as  is  common  in  geometry,  this  won't  be 
needed.  It  is  important  to  note  that  the  angle  terms  refer  to  the  particular  piece  of  angle  subtended 
by  the  particular  three  points,  so  our  geometrical  theorems  will  not  state  that  angles  are  equal,  but 
that  their  sises  are  equal;  similarly,  lines  are  not  equal,  but  have  equal  length. 

A  real  difhculty  arises  with  the  use  of  an  angle  described  by  a  term  such  as  (Angle  ABC): 
how  is  MRS  to  know  that  it  is  the  same  as  (Angle  C  B  A}?  The  same  problem  arises  with  (Line 
A  B)  and  (Line  B  A).  Basically  whenever  we  want  to  use  a  term  such  as  (Angle  $a  $b  $c)  in  a 
rule,  we  are  obliged  to  write  the  same  r  vie  again  but  with  the  points  in  reverse  order,  in  case  the 
facts  we  have  about  that  angle  happen  to  be  expressed  that  way.  It  would  be  nice  if  we  could  get 
the  unification  routine  to  treat  these  as  unifiable,  then  we  could  write  rules  and  describe  problem 
instances  as  if  there  were  no  problem  at  all,  but  that  is,  as  they  say,  beyond  the  scope  of  this  book. 
There  is,  however,  a  way  of  achievmg  the  same  effect.  What  we  want  to  have  is  a  term  that  will 
unify  with  a  given  angle  whichever  way  round  it  is  written;  to  achieve  this  we  use  a  constructor 
predicate  MakeAngle: 

(MakeAngle  $a  $b  $c  (Anglo  $a  $b  $c}) 

(MakeAngle  $a  $b  $c  (Anglo  $c  $b  la)) 

Wherever  we  want  to  use  (Anglo  |a  $b  |c)  we  now  say 

(MakeAngle  |a  |b  |c  |abc) 

and  use  labc  instead.  The  caJ  to  MaktAnglo  succeeds  twice  if  necessary  to  we  can  treat  $abc  as  if 
it  were  an  'unordered*  representation  of  the  angle  that  unifies  with  either  of  the  ordered  versions. 
Let  us  see  how  this  works  in  a  simple  case,  the  rule  for  calculating  the  third  angle  of  a  triangle  when 
the  other  two  are  given.  The  original  rule,  which  is  inadequate,  is 

(IF  (AND  (DegreeValuo  (Anglo  $b  la  |c)  Ibacval) 

(DegreoValuo  (Anglo  la  |e  lb)  lacbval) 

(*  180  Ibacval  lacbval  labcval)) 

(DegreoValuo  (Anglo  |a  |b  |c)  labcval)). 

The  first  stab  at  fixing  it  up  is 

(IF  (AND  (MakeAnglo  la  |b  |c  labc) 

(MakeAngle  lb  la  Ic  Ibac) 

(MakeAnglo  la  Ic  lb  lacb) 

(DegreoValuo  Ibac  Ibacval) 

(DegreoValuo  lacb  lacbval) 

(-  180  Ibacval  lacbval  labcval)) 

(DegreeValuo  labc  labcval)) 

but  this  rule  is  actually  too  general,  since  we  will  be  normally  trying  to  find  some  fixed  angle  labc 
so  we  can  dispense  with  that  variable  and  its  corresponding  MakeAngle  and  use  (Angle  la  lb  Ic) 
in  the  conclusion  of  the  rule,  as  it  appears  in  the  body  of  the  code  below.  In  general,  facts  such 
as  actual  angle  values  in  the  database  will  have  a  fixed-order  representation  (we  don’t  want  to  give 
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each  fact  for  a  problem  instance  twice),  so  to  achieve  generality  the  premises  of  rules,  which  will 
be  unified  with  facts  in  the  database,  should  use  the  KakeAngle  method,  whibt  the  conclusions  can 
be  in  fixed  format.  If  we  had  the  multiple  representations  of  the  problem  instance  we  could  use 
MakcAnglc  for  angles  in  the  conclusions  of  rules  and  fixed  format  for  those  in  the  premises.  The  key 
is  to  be  consistent. 

The  following  rules  contain  the  geometrical  theorems  that  are  useful  for  this  proof: 

;The  angle  between  a  tangent  and  a  radius  to  the  point  of  contact  is  90 

(IF  (AND  (MakeLine  U  $b  tab) 

(Tangent  $ab  tcircle) 

(Center  tcircls  $o) 

(PointOnCircle  $b  tcircle)) 

(DcgreeValue  (Angle  ta  $b  $o)  90)) 

;The  angles  in  a  triangle  add  up  to  180  (for  deducing  3rd  angle  value) 

(IF  (AND  (MakeAngle  $b  $a  $c  $bac) 

(KakeAngle  $a  $c  $b  $acb) 

(DegreeValue  $bac  tbaeval) 

(DegreeValue  $acb  tacbval) 

(-  180  tbaeval  tacbval  tabeval)) 

(DegreeValue  (Angle  $a  $b  tc)  tabeval)) 

: Angle  at  the  centre  is  twice  the  angle  at  the  circumference 

(IF  (AND  (PointOnCircle  $a  tcirclc) 

(PointOnCircle  $b  Icircle) 

(Unknown  («  $a  $b))  r 

(PointOnCircle  $c  tcircle) 

(Unknown  («  $a  $c)) 

(Unknown  (*  $c  $b)) 

(Center  tcircle  $o) 

(MakeAngle  $a  $o  $c  $aoc) 

(DegreeValue  $aoc  taoeval) 

(//  taoeval  2  tabeval)) 

(DegreeValue  (Angle  $a  $b  $c)  tabeval)) 

;The  angles  at  the  base  of  an  isosceles  triangle  are  equal 

(IF  (AND  (MakeAngle  $b  $a  $c  $bac) 

(MakeLine  $b  $a  $ba) 

(MakeLine  $b  $c  $bc) 

(EqualLength  $ba  $bc) 

(MakeAngle  $a  $e  $b  $acb) 

(DegreeValue  $acb  $val)) 

(DegreeValue  $bac  $val)) 
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:AI1  radii  of  m  given  circle  have  tqu&l  length 

(IF  (AND  (PointOnCircle  U  $clrcle) 

(Point OnCircle  $b  $circle) 

(UakaoTO  (•  $«  $b)) 

(Center  Scircle  $o)} 

(£qualX.ength  (Lise  $o  $t)  (Line  $o  $b))} 

;Angles  etending  on  the  sane  eegaent  ere  equal 

(IF  (AND  (PointOnCixcle  $a  (circle) 
(PointOnCircle  $b  (circle) 

(Unknown  (■•  (a  (b)) 

(PointOnCixcle  (c  (circle) 

(Unknown  (*  (a  (c)) 

(Unknown  (*  (c  (b)) 

(PointOnCircle  (d  (circle) 

(Unknown  (•  (a  (d)) 

(Unknown  (-  (b  (d)) 

(Unknown  («  (c  (d)) 

(MakeAngle  (a  (d  (c  (adc) 

(DegreeValue  (adc  (val)) 

(DegreeValue  (Angle  (a  (b  (c)  (val)) 

;lf  P  is  on  AB  then  <ABC  »  <PBC 

(IF  (AND  (MakeLine  (a  (b  (ab) 

(PointOnLine  (p  (ab) 

(MakeAngle  (a  $b  (c  (abc) 

(DegreeValue  (abc  (val)) 

(DegreeValue  (Angle  (p  (b  (c)  (val)) 

: If  A  is  on  PB  then  <ABC  -  <PBC 

(IF  (AND  (MakeLine  (p  (b  (pb) 

(PointOnLine  (a  (pb) 

(MakeAngle  (a  $b  (c  (abc) 

(DegreeValue  (abc  (val)) 

(DegreeValue  (Angle  (p  (b  (c)  (val)) 

; Angle  and  line  constructors 

(MakeAngle  (x  (y  (z  (Angle  (x  (7  (z)) 

(MakeAngle  (z  (y  (x  (Angle  (x  $y  (z)) 

(MakeLine  (x  (y  (Line  (x  (y)) 
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(MakeLine  $y  $x  (Lin®  Jy)) 

The  following  is  the  description  of  the  problem  instance.  These  facts  should  probably  be  asserted 
with  forward  chaining  turned  on. 

(PointOnCircle  B  Q) 

(PointOnCircle  C  Q) 

(PointOnCircle  D  Q) 

(PointOnCircle  £  Q) 

(PointOnCircle  F  Q) 

(Center  Q  0) 

(Tangent  (Line  A  B)  Q) 

(PointOnLine  F  (Lino  A  0)) 

(PointOnLine  0  (Line  F  D)) 

(PointOnl.ine  0  (Line  B  £)) 

(DegreeValue  (Angle  0  A  B)  20} 
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§B.l  Introduction 

There  are  three  different  machines  upon  which  this  MRS  will  run.  They  arc  DEC-2(y8  running 
Maclisp,  VAXen  running  Frans  under  Berkeley  Unix,  and  Symbolics  LISP  Machine  LM-2/S600. 
Each  machine  requires  a  slightly  different  set  of  miscellanous  files  and  slight  changes  in  the  file 
extensions.  The  package  you  received  has  lisp  file  extensions  .Isp  (DEC-20),  .1  (VAX)  or  .lisp 
(LM-2/3600).  In  the  remainder  of  the  document  the  lisp  files  will  be  referred  to  as  <file>.l8p/  the 
reader  should  translate  this  into  the  appropriate  extension  for  their  machine. 

Besides  the  lap,  test,  load,  dat,  sirs,  demo  and  doc  files  which  are  used  by  aD  the  systems, 
there  are  several  files  and  file  types  which  are  unique  to  each  individual  machine.  Each  is  explained 
in  the  appropriate  section. 


Extension 

Machine 

.CTL 

DEC-20 

•VAX 

VAX 

Makefile 

VAX 

.LM2 

LM-2 

|B.2  How  to  get  MRS  running 

B.2.1  Maclisp  version  on  the  D£C>20« 

Dec.20  tapes  are  written  usbg  the  ANSI  tape  program.  The  files  from  the  tape  should  be  read 
into  the  directory  in  which  they  will  reside  on  your  machine.  We  maintain  the  files  in  the  directory 
<nrs.mac.cur>.  There  are  several  locations  where  the  directory  name  is  defined.  THESE  MUST 
BE  UPDATED  TO  YOUR  DIRECTORY  NAME.  The  locations  are  in  all  the  CTL  files  amd  in 
MRS. LOAD. 

There  is  an  automatic  compilation  program  which  will  compile  all  the  required  lisp  programs. 
It  can  be  run  in  batch  by  -SUBMIT  COMPMRS.CTL-.  A  summary  of  the  resulU  wiU  be  appended  to 
the  file  compmrs .  log.  If  you  need  to  compile  individual  files,  then  make  sure  you  are  connect  to  the 
directory  and  then  run  complr. 

To  make  an  executable  v-tjion  of  MRS,  run  in  batch  -SUBMIT  MAKMRS.CTL-.  The  resulting 
executable  file  will  reside  jx  nrs.exe.  Again  a  log  of  the  results  of  the  batch  run  is  appended  to 
MAKHRS.CTL. 

You  are  now  .eady  to  start  using  MRS. 

(The  fil  prmrs.ctl  is  used  to  print  out  the  appropriate  files  on  our  laser  printer  .  This  is  not 
necessary  but  is  provided  as  a  convenience) 

B.2.2  Franz  version  on  the  VAX. 

Rrans-MRS  tapes  usually  are  written  by  the  UNIX  program  tar.  After  you  connect  to  the 
directory  where  you  want  to  put  the  sources,  restore  them  with  the  command  tar  -xp.  (The 
directory  does  not  have  to  be  dedicated  to  MRS  but  this  is  recommended.) 

There  are  several  locations  where  the  directory  name  is  defined.  THESE  MUST  BE  UPDATED 
TO  YOUR  DIRECTORY  NAME.  The  locations  are  in  nrs.load  and  Makefile.  The  current 
reference  should  be  to  /hpp/mrs/ciir  and  should  be  changed  to  the  directory  name. 
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The  file  ‘•Makefile"  sets  the  variables  LISP  (which  points  to  the  directory  that  contains 

•lisp*  and  "liszt*),  DESTDIR  (which  points  to  the  directory  where  the  MRS  executable  file  should 
be  linked  to},  and  LIBDIR  (which  points  to  the  directory  where  the  library  files  should  be  linked  to). 
Modify  these  files  for  your  site. 

The  file  "Makefile"  will  be  used  by  "make"  to  build  an  MRS  for  you.  You  must  modify  the 
install  command  so  that  it  sets  up  the  links  correctly.  (If  you  don’t  want  the  library  files  to  be 
linked  to  another  directory,  this  is  the  place  to  change.)  If  you  are  just  interested  in  a  sysout,  the 
command  "make  xmrs"  should  put  an  executable  version  of  MRS  into  the  file  "xmrs". 

*^aakt  Install"  w'il  create  a  xzsrt  in  this  directory,  and  also  put  in  a  Vt\  between  the  DEST- 
DIR/ars  and  the  xmrs  created  in  this  directory.  Only  the  executable  file  is  linked. 

You  are  now  ready  to  start  using  MRS. 

There  are  three  files  with  the  extension  .VAX. 

The  getfxanz.  VAX  is  used  to  FTP  the  MRS  from  our  DEC-20  to  our  VAX  If  you  have  multiple 
sites  running  MRS  this  program  can  be  used.  It  will  have  to  be  altered  to  your  protocols.  Notice 
the  name  changing  from  DEC-20  to  VAX 

The  sendf  ranz .  VAX  is  used  to  FTP  the  MRS  from  our  VAX  to  our  DEC-20.  If  you  have  multiple 
sites  running  MRS  this  program  can  be  used.  It  will  have  to  be  altered  to  your  protocols.  Notice 
the  name  changing  from  VAX  to  DEC*20.  (getfranz  and  sendf  ranz  are  just  opposite  directions) 

The  sendllspm.VAX  is  used  to  FTP  the  code  from  our  VAX  to  the  Symbolics  machines.  Notice 
the  name  changing  from  VAX  to  LISPM. 

The  technique  for  using  getfranz  and  sendf  ranz  is 
cat  getfranz.VAX  I  ftp 

the  technique  for  using  sendlispm  is: 
cat  sendllspm.VAX  I  ftp 


B.2.8  ZetaLisp  version  on  the  LM-2/SC00. 

The  lispm-MRS  tapes  are  written  on  Symbolics  streamer  tapes.  The  tape  was  made  using  the 
LMFS  dumper  and  was  a  complete  dump  of  the  MRS  directory.  The  tape  can  be  loaded  using  the 
relosd/retrieve  command  on  the  directory  yon  intend  to  install  MRS.  The  tape  name  is  MRS-7.1 
(or  a  later  version  number).  Lisp  files  on  the  Symbolics  machines  should  end  with  extension  .LISP. 

There  is  one  locations  where  the  directory  name  is  defined  in  the  MRS  files.  THIS  MUST  BE 
UPDATED  TO  YOUR  DIRECTORY  NAME.  The  location  is  in  sirs. load.  The  current  reference 
should  be  to  >mrs>cur>  and  should  be  changed  to  the  directory  name. 

To  load  MRS  into  the  current  lisp  environment  do  the  following: 

(load  *>mrs>c\ir>mrs.load) 


This  should  compile  the  appropriate  lisp  functions  and  load  them  in.  There  will  probably  be  a 
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lot  bf  warning  messages  in  the  compilation.  These  on  the  most  part  can  be  ignored.  It  is  advised 
that  MRS  be  leaded  into  a  clean  cold  boot.  Otherwise  names  may  be  redefined. 

§B.3  Adding  Files  to  MRS  •  for  system  maintauiers 

If  you  need  to  add  a  new  set  of  source  file  to  MRS,  there  are  several  files  that  are  affected  and 
need  to  be  changed.  They  are  MRS. LOAD  ,  Makefile,  COMPMRS.CTL,  PRMRS.CTl,  COPYLISPM . VAX, 
GETFRANZ.VAX,  SEN  Dr  RAN  Z.  VAX,  and  SENDLISPM.VAX.  The  files  interface. Isp  and  test.lep  are 
affected  if  new  demo  packages  are  added  or  test  files  respectively. 

In  MRS. LOAD  two  references  to  the  lisp  source  filename  (excluding  the  lisp  extension)  need  to  be 
added 

In  Makefile  the  source  filename  (with  .1  extension)  needs  to  be  added  to  the  make  variable 
SOURCES,  the  object  filename  (with  .o  extension)  needs  to  be  added  to  the  make  variable  OBJECTS, 
the  test  filename  (with  .test  extension)  needs  to  be  added  to  the  make  variable  TESTAUX,  and  the 
demo  filename  (with  .demo  extension)  needs  to  be  added  to  the  make  variable  DEMOAUX. 

In  files  COI^MRS.CTL  and  PRMRS.CTL  need  to  add  the  source  filename  (with  .lap  extension). 

In  files  COPYLISPM. VAX,  GETFRANZ.VAX,  SENDFRAMZ.VAX,  and  SENDLISPM.VAX  need  to  add  the 
source  filename  (with  extension),  the  test  filename  (with  extension  .test)  if  one  exists,  and  the 
documentation  filename  (with  extension  .doc)  if  one  exists. 

If  there  are  any  demo  files,  they  need  to  be  added  to  the  list  demoliat  in  the  source  file 
INTERFACE. LSP. 

If  there  are  any  test  files,  they  need  to  be  added  to  the  function  f  inderrora  in  the  source  file 
TEST. LSP. 

§B.4  Testing  MRS  installation 

There  is  a  testing  program  for  verifying  the  system.  Once  MRS  has  been  installed  call  (f  inderrora) ; 
it  should  return  a  value  of  0  indicating  that  there  were  no  errors  encountered.  If  there  are  errors  in 
the  MRS  function  being  tested,  the  result  and  the  expected  result  are  indicated. 

If  yon  plan  on  adding  teat  files  you  are  required  to  follow  a  specific  format.  The  format  consists 
of  an  MRS  (or  LISP)  command  followed  by  the  expected  answer.  If  the  answer  is  irrelevant  a  ♦  can 
be  lued.  For  examples,  look  at  the  <f  lle>.teat  source  files. 

§B.5  The  Share  Subdirectory 

We  are  also  maintaining  a  subdirectory  called  share  which  ia  composed  of  user  written  code  that 
may  be  useful  to  other  sites.  These  procedures  are  not  currently  considered  a  core  part  of  MRS  and 
hence  are  not  in  the  main  directory.  All  files  maintained  in  this  subdirectory  should  have  a  •.doc 
file  describing  tlie  use  and  functions  m  the  file  and  •.diet  file  consisting  of  a  dictionary  entry  for 
each  of  the  user  accessable  functions/procedures/relations. 
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§B.6  Requited  Files 

This  is  a  list  of  the  required  hies  that  should  be  on  your  tape.  There  may  be  additional  hies  which 
can  be  ignored. 

LISP  files  Demo  files  MRS  files  used  by  demo,  test 


ask. Isp 

blocks. demo 

blocks. BTS 

bass. Isp 

d74.deBO 

fi.BTS 

batch. Isp 

kinship. demo 

kinship. ars 

be. Isp 

overview. demo 

meta.Bxs 

cnf.Isp 

primate. demo 

BTS.BXS 

conaon.Isp 

tax. demo 

BSai.BTS 

compat . lap 

primate. BTS 

erfrepn.Isp 

Test  files 

S.BTS 

execute. Isp 

sets.mrs 

ic.Isp 

base. test 

syntax. BTS 

interface. Isp 

be. test 

tax. BTS 

macros. Isp 

erf repn. test 

match. Isp 

execute. test 

VAX  files 

Beta. Isp 

fl.test 

mla.lsp 

fc.test 

Makefile 

plist.Isp 

Beta. test 

ReadMe 

proprep.Isp 

Bla.test 

copylispa.vax 

repn.Iap 

pr opr ep. test 

getfranz.vax 

res. Isp 

repn. test 

sendfranz.vax 

set .Isp 

res. test 

sendlispm.vax 

test. Isp 

set .test 

timer. Isp 

tr.test 

DEC-20  files 

tm . Isp 

trbc.test 

top. Isp 

trfc.test 

compars.ctl 

toplevel.Isp 

Bakars.ctl 

tr.lsp 

prars.ctl 

trbe . lap 
trexec.Isp 
trfc.lsp 
tut*co&cpt . Isp 
tut'-dict  .lap 
tut^txtr.lsp 
tut-gen.lsp 
tut -main. Isp 
tut-aynchk.lsp 
tut-topics. Isp 
version. Isp 
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«  (•  <•!>...<«,♦>  <Un^i>) 

means  that  <tn+i  >  represents  the  product  of  the  values  represented 
by  <Ux  >.  See  fq. 

means  that  <an+i  >  represents  the  sum  of  the  values  represented  by 
<ai  >...<a,»  >.  See  fq* 

(-  <a>  <b>  <c>) 

means  that  <c>  represents  the  difference  between  <a>  and  <b>.  See 

^q- 

//  (//  <a>  <b>  <c>) 

means  that  <c>  represents  the  quotient  of  <a>  and  <b>.  See  fq. 

<  (<  <a>  <b>) 

means  that  <a>  is  less  than  <b>.  See  rq. 

<-  {<-  <a>  <b>) 

means  that  <a>  is  less  than  or  equal  to  <b>.  See  rq. 

-  (-  <a>  <b>) 

means  that  the  terms  <a>  and  <b>  are  synonymous,  Le.  they  refer  to 
the  same  object.  See  lookup*". 

>  (>  <a>  <b>) 

means  that  <a>  is  greater  than  <b>.  See  rq. 

>-  (>-  <a>  <b>) 

means  that  <a>  is  greater  than  or  equal  to  <b>.  See  rq. 

achieve  (achieve  <p>) 

makes  the  proposition  <p>  true.  Achieve  is  an  abstract  operator  imple¬ 
mented  using  kb  and  toachieve.  (achieve  <p>)  and  (achieve  (not 
<p>))  now  work  when  the  proposition  <p>  begins  with  value,  prop¬ 
erty,  repn,  threpn,  includes,  indb,  better,  or  primitive.  So,  up  to 
a  point,  does  (achieve  (if  <q>  <p>)),  which  calls  trueps  on  <q> 
and  then  ACHIEVES  <p>  with  the  resulting  bindings  plugged  in.  Note 
that  propositions  stashed  in  theories  other  than  the  currently  wrriteable 
one  are  not  affected,  (e.g.  (achieve  (repn  <p>  <r>))  has  the  re¬ 
sult  that  all  propositions  matching  <p>  will  henceforth  be  stashed, 
lookuped,  and  so  on  using  representation  <r>.  This  includes  re-storing 
currently  accessible  propositions  that  were  stored  using  pr- stash  or  in 
enf .  repn  works  on  all  theories  that  are  active  when  it  is  achieved, 
(achieve  (threpn  <p>  <r>  <th>))}  does  the  same  thing  as  with 
repn,  but  affecting  only  theory  <th>.  It  is  the  users  responsibility  to  en¬ 
sure  that  there  are  never  two  or  more  theories  active  which  use  different 
representations  for  the  same  proposition.)  See  kb,  repn,  threpn. 

achieve-if  (achieve-if  (if  <p>  <q>)) 

has  the  effect  of  calling  achieve  on  the  proposition  <q>  for  each  list 
of  variable  bindings  that  makes  proposition  <p>  true,  with  the  relevant 


J 


achieve -not 


achieve-repa 


achieve-threpn 


activate 


activetheories 


agenda 

and 


applicable 


arity 


ask 


asks 
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bindings  substituted  into  <q>.  See  achievei  tz^eps,  plug, 
(achieve-not  (not  <p>)) 

is  an  abstract  opciator  implemented  using  kb  and  tounachieve.  When 
called  with  an  argument  of  the  form  (not  <p>),  it  is  supposed  to 
achieve  the  opposite  of  <p>,  if  meaningful.  See  achieve,  imachieve. 

(achieve-repn  (repn  <prop>  <rpn>)) 

uses  repn-assert  to  switch  the  representation  of  <prop>  from  its  old 
value  to  <rpn>,  and  converts  any  instances  of  <prop>  that  can  be 
found  under  the  old  representation  to  the  new  one.  See  domain,  repn, 
repn-assert,  repn-methocL 

(achieve-threpn  (repn  <prop>  <rpn>  <th>)) 
is  identical  to  achiov^-repn  except  that  it  sets  the  currently  writable 
theory  to  <th>  temporarily  while  it  executes.  See  achieve-repn,  the¬ 
ory,  threpn. 

(activate  <tx  >  ...  <tn  >) 

makes  the  propositions  in  the  theories  <ti  >  ...  <tn  >  available  for 
retrieval  or  deduction.  See  theory,  activetheories,  deactivate. 

has  as  its  value  the  list  of  currently  active  theories.  The  propositions  in 
these  theories  are  available  for  retrieval  by  pr-lookup  and  pr-lookups. 
See  pr-atash,  pr-unatash,  pr-lookup,  pr-lookups,  activate,  and  de¬ 
activate. 

agenda  is  a  list  of  applicable  tasks.  See  applicable,  scheduler. 

(and  <pi  >  . . .  <pn  >) 

means  that  the  propositions  <px  >  . . .  <Pn  >  are  all  true.  See  assert- 
and,  be,  br,  f  c. 

(applicable  <k>) 

states  that  the  task  <k>  is  applicable  and,  therefore,  executable  unless 
it  is  disqualified.  See  executable,  disqualified,  scheduler. 

(arity  <rel>  <i>) 

provides  typing  information,  indicating  that  the  relation  (or  operation) 
<rel>  takes  <i>  arguments,  e.g.  (erity  arity  2).  See  domain. 

(ask  <p>) 

calls  output,  prints  the  result,  and  reads  the  users  answer.  If  <p>  is 
a  ground  proposition,  ask  tries  to  obtain  an  answer  of  true  or  false. 
If  <p>  contains  variables,  ask  obtains  variable  bindings  from  the  user. 
See  output. 

(asks  <p>} 

calls  output,  prints  the  result,  and  reads  the  users  answers.  If  <p>  is 
a  ground  proposition,  asks  tries  to  obtain  an  answer  of  true  or  false. 
If  <p>  contaiiiS  variables,  asks  obtains  a  list  of  binding  lists  from  the 
user.  See  output. 
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asaert 


aasert-and 


assert-iff 


assumable 


bagof 


batcbp 


be 


bedisp 


(assert  <p>} 

stores  the  proposition  <p>  in  the  data  base  and  performs  all  appropriate 
fonvard  inference.  Assert  is  an  abstract  operator  implemented  using  kb 
and  toassert. 

(assert*and  (and  <pi  >  •••  <pn  >)) 
separately  asserts  each  of  the  conjuncts  <pi  >,. . <pn  >* 

(ass«rt-iff  (iff  <p>  <q>)) 
asserts  (if  <p>  <q>)  and  (if  <q>  <p>).* 

(assuaabls  <p>) 

means  that  the  proposition  <p>  can  be  assumed  if  necessary  in  trying 
to  prove  a  proposition.  See  residue,  residues. 

(bagof  <x>  <p>  <8>) 

means  that  <8>  is  the  bag  of  all  objects  <x>  that  statisfy  <p>.  Smee 
there  maybe  many  ways  of  satisfying  <p>,  the  bag  <b>  may  contain 
duplicate  objects.  Bagof  is  useful  for  performing  extensional  reasoning, 
since  it  allows  one  to  designate  the  set  of  all  solutions  to  a  problem.  See 
truep*bagof ,  lookup**bagof . 

(batchp  <x>  <y>) 

checks  whether  the  expressions  <x>  and  <y>  can  be  unified  by  some 
set  of  bindings  for  the  base-level  variables  in  the  two  expressions.  If  so, 
batchp  returns  the  corresponding  binding  list  for  the  variables  in  <x> 
but  discards  the  bindings  for  the  variables  in  <y>.  If  the  expressions 
are  not  unifiable,  batchp  returns  nil.  All  variables  in  <x>  are  treated 
as  distinct  from  the  variables  in  <y>,  even  though  they  have  the  same 
name.  For  example,  the  expression  (r  $x  b)  matches  (r  a  $x)  with 
result  (($x  •  a)  (t  •  t)).  See  blvarp,  natchp. 

(be  <p>) 

tries  to  prove  the  proposition  <p>.  If  successful,  it  returns  an  appropri¬ 
ate  binding  list;  otherwise,  it  returns  nil.  Only  base-level  variables  are 
treated  as  variables  by  be,  and  any  meta-level  variables  are  treated  as 
constants.  The  inference  procedure  used  is  backward  chaining,  but  there 
are  also  built-in  procedural  attachments  for  many  propositions  (specified 
via  the  totniep  and  tot  maps  relations).  Be  is  implemented  using  the 
subroutine  bedisp.  See  bedisp,  scheduler. 

(bedisp  <gl>  <4l>  <jl>  <ce>) 

performs  one  backward  chaining  step  in  trying  to  prove  the  propositions 
on  the  goal  list  <gl>.  The  binding  list  <al>  holds  bindings  for  the  vari¬ 
ables  in  <gl>  obtained  in  preceding  steps.  The  justification  list  <J1> 
holds  the  names  of  any  propositions  used  in  deriving  a  goal  list  from  its 
super  goal  list.  The  list  <ce>  is  a  stack  of  supergoals  and  justifications. 
In  working  on  a  goal  list  (<q>  .  <!>},  bedisp  first  calls  trtruep  to 
find  any  procedural  attachments  for  <q>  other  than  be  or  bes,  and 
if  successful  calls  that  subroutine.  Otherwise,  it  generates  subgoals  by 
looking  in  the  data  base  for  propositions  of  the  form  <q>  or  (if  <p> 
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bC9 


blvarp 


br 


brdiep 


<q>).  The  order  in  which  multiple  bcdiap  tasks  are  executed  can  be 
influenced  via  appropriate  preferred  propositions,  bcdiap  caches  its 
results  and  saves  justifleations  as  appropriate.  See  trtruep,  totruep, 
totmepa,  cachoi  Justify. 

(bet  <p>) 

tries  to  prove  the  proposition  <p>.  It  returns  a  list  of  all  binding  lists  for 
which  it  b  successful*  Only  base*level  variables  are  treated  as  variables  by 
bes,  and  any  meta-level  variables  are  treated  as  constants.  The  inference 
procedure  used  b  backward  chaining,  but  there  are  also  built-in  proce¬ 
dural  attachments  for  many  propositions  (specified  via  the  totruep  and 
totrueps  relations).  Bca  b  implemented  using  the  subroutine  bedisp. 
See  bedisp  and  scheduler. 

(blvarp  <xp>) 

returns  a  non-nil  value  if  <xp>  b  a  base-level  variable  and  otherwbe 
returns  nil.  A  base-variable  in  MRS  b  denoted  by  a  doUarsign  prefix 
($)  and  b  internally  dbtingubhed  by  the  value  bl.  For  example,  $a  b  a 
base-level  variable.  See  varp. 

(br  <p>) 

tries  to  prove  the  proposition  <p>.  If  succesful,  it  returns  a  Ibt  of 
assumable  propositons  which,  when  added  to  the  data  base,  imply  <p>. 
Only  base-level  variables  are  treated  as  variables  by  br,  and  any  meta¬ 
level  variables  are  treated  as  constants.  The  inference  procedure  used  b 
backward  chaining,  but  there  are  abo  built«m  procedural  attachments  for 
many  propositions  (specified  via  the  totruep  and  totrueps  relations). 
Br  b  implemented  using  the  subroutine  brdisp.  See  brdisp,  scheduler, 
and  assumable. 

(brdisp  <gl>  <al>  <th>  <J1>  <ce>) 

performs  one  backward  chaining  step  in  trying  to  find  a  residue  for  the 
propositions  on  the  goal  Ibt  <gl>.  The  binding  Ibt  <al>  holds  bindings 
for  the  variables  in  <gl>  obtained  in  preceding  steps.  The  theory  <th> 
contams  all  assumptions  made  so  far.  The  justification  Ibt  <J1>  holds 
the  names  of  any  propositions  used  in  deriving  a  goal  Ibt  from  its  super 
goal  Ibt.  The  Ibt  <ce>  b  a  stack  of  supergoab  and  justifications.  In 
working  on  a  goal  Ibt  (<q>  .  <1>),  brdisp  first  calb  trtruep  to 
find  any  procedural  attachments  for  <q>  other  than  be  or  bes,  and  if 
successful  calb  the  subroutine  so  found.  Otherwbe,  it  generates  subgoab 
by  looking  in  the  data  base  for  propositions  of  the  form  <q>  or  (if 
<p>  <q>}.  It  trueps  to  dbcover  whether  q  b  assumable.  If  it  b 
assumable  and  if  b  a  ground  proposition  after  plugging  in  the  variable 
bindings  returned  by  trueps,  brdisp  creates  a  new  theory  that  includes 
<th.  *  asserts  the  proposition  in  that  theory,  and  generates  appropriate 
subgoab.  The  asserted  propositions  are  useful  in  that  they  make  possible 
consbtency  checking  before  making  assumptions  in  subsequent  steps. 
The  order  in  which  multiple  brdisp  tasks  are  executed  can  be  influenced 
via  appropriate  preferred  propositions.  Brdisp  caches  its  results  and 


so 
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brs 


caibe 


cachebystash 


characteristic 


c&f 


cxif-asaert 


cnf-imassert 


computable-repn 


•avea  justificatioxu  as  appropriate.  See  trtruep,  totruep,  totnieps, 
cache,  Justify. 

(brs  <p>) 

tries  to  prove  the  proposition  <p>.  It  returns  a  list  of  all  assumption 
lists  for  which  it  is  succmful.  Only  base-level  variables  are  treated  as 
variables  by  brs,  and  any  meta*level  variables  are  treated  as  constants. 
The  inference  procedure  used  is  backward  chaining,  but  there  are  also 
built-in  procedural  attachments  for  many  propositions  (specified  via  the 
totruep  and  totrueps  relations).  Brs  is  implemented  using  the  subrou¬ 
tine  brdisp.  See  brdisp,  scheduler,  and  aeeusiable. 

is  a  variable  governing  whether  various  inference  methods  should  cache 
their  results.  When  nonNIL,  those  various  inference  methods  will  call 
the  appropriate  tocache  method  on  each  cachable  result.  (I.e.,  each 
method  will  call  (kb  tocache  <p>)  for  each  intermediate  conclusion, 
<p>.)  See  tocache,  cachebyetash. 

(cachebyetash  <p>) 

stashes  the  value  <p>  into  the  theory  named  by  the  variable  cache. 
(If  cache  has  the  value  T,  then  the  current  theory  is  used.)  This 
cachebyetash  subroutine  is  the  default  caching  method.  It  is  recom¬ 
mended  that  one  house  these  propositions  in  a  temporary  theory,  and 
apply  empty  to  this  theory  when  the  cached  values  are  no  longer  needed. 
See  cache,  tocache 

(characteristic  <eet>  <fn>) 

means  that  the  lisp  subroutine  <fn>  is  the  characteristic  function  for 
the  set  <eet>,  e.g.  (characteristic  integers  fixp).  See  arity. 
domain. 

is  short  for  conjunctive  normal  form.  A  proposition  is  in  conjunc¬ 
tive  form  if  it  is  written  as  a  conjunction  of  disjunctions  of  literals, 
Le.  atomic  propositions  or  negations  of  atomic  propositions.  For  ex¬ 
ample,  the  proposition  (and  (or  (not  (p  $x)}  (q  $x))  (or  (r  $x} 
(s  $x}})  is  in  conjunctive  form.  This  also  serves  as  a  representation. 
See  repn. 

(enf^assert  <p>} 

converts  <p>  into  conjunctive  normal  form  and  separately  asserts  each 
of  the  conjuncts.  See  enf  • 

(cnf*unassert  <p>} 

converts  <p>  into  conjunctive  form  and  separately  unasserts  each  of  the 
conjuncts.  See  cnf. 

Explanation. 

Many  relations  and  functions  can  be  readily  evaluated,  and  so  never 
need  to  be  explicitly  stashed.  Consider,  for  example,  the  class  of  arith¬ 
metic  functions  and  relations,  such  as  and  >.  MRS  includes  several 
computable  representations  in  which  to  encode  such  facts.  We  describe 
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below  vario’js  computable  rcprcaeiitations  -  via.,  re,  rq,  rqb,  rqbn,  reb, 
rebn,  rqfm,  fc,  fq  and  fea.  For  a  proposition  to  be  represented  in 
one  of  these  representation,  its  relation  symbol  must  hi^ve  an  associated 
LISP  subroutine  (ALS).  Each  lookup  subroutine  associated  with  each 
of  these  representations  takes  as  input  a  proposition  of  the  form  (<r> 
<Xi  >  ...  <Xn  >),  and  calls  ALS  on  a  list  of  values  comp^Ued  ^*‘om 
that  argument  list,  <xi  >  ...  <Xn  >.  In  some  representations,  each 
argument  is  Erst  evaluated,  using  lookupval.  Also,  in  seme  represen* 
tations  the  ALS  takes  all  n  arguments,  while  in  others  it  is  only  passed 
the  term-part  of  the  proposition,  namely  the  Erst  n-^1  arguments.  Note 
that  propositions  stored  in  this  way  are  not  associated  with  any  par¬ 
ticular  theory  and  cannot  be  found  by  PR*based  routines  like  prfacts 
or  preontents.  The  details  of  these  representations  are  specified  in 
the  Computabla-Repn  (Relation)  and  Computable-Repn  (Function) 
entries.  These  representations  are  used  by  the  funproc  and  relnproc 
relations. 

computable  *repn  Functions. 

Here  we  describe  those  computabla-rcpn  representations  which  arc 
based  on  a  function.  We  designate  these  function-based  representations 
by  using  the  letter  F  in  the  Erst  position  of  the  name  of  the  representation 

-  e.g.  Fq  is  a  function-based  representation.  Here,  only  the  term  part  of 
the  proposition  is  passed  to  the  ALS;  and  it  is  the  responsibility  of  the 
associated  lookup  subroutines  to  bind  thb  returned  value  appropriately. 
The  same  second  letter  is  £  for  Eval,  Q  for  Quote  convention  used  for 
the  relation-based  representations  applies  here  as  well.  Hence  lookup 
subroutines  associated  with  the  FE  representation  will  first  lookupval 
each  of  the  arguments  <xi  >  . . .  <x,*^i  >,  passing  the  resulting  list 
to  the  ALS.  The  only  (current)  additional  letter  for  function-based  rep* 
resentations  is  A,  for  arithmetic.  This  uses  NUM—  rather  than  UNIFY? 
when  comparing  the  value  associated  with  the  term  of  the  proposition 
with  the  value  of  the  proposition.  See  computable-repn,  f e,  f ea,  fq. 

computable -repn  Relations. 

This  section  describes  those  computable *repn  which  representations  axe 
based  on  relations.  These  relation-based  representations  axe  designated 
by  usmg  the  letter  R  in  the  first  position  of  the  name  of  the  represenation 

-  c.g.  Erq  is  a  relation-based  representation.  With  one  exception,  the 
ALS  takes  a  spread  version  of  the  full  proposition  as  its  argumenf  s.  If  the 
second  letter  is  E  for  eval,  (as  in  xEbm,)  the  associated  lookup  methods 
will  first  call  lookupval  on  each  embedded  term,  and  pass  that  evaluated 
argument  list  to  the  ALS.  Otherwise,  when  it  is  Q  for  quote,  those  ar¬ 
gument  are  directly  passed  to  the  ALS.  By  default,  the  value  returned 
by  the  ALS  is  an  arbitrary  value  which,  when  nonNIL,  tells  the  lookup 
subroutine  that  this  propostion  is  true.  The  third  and  fourth  letter  en¬ 
code  further  refinements:  When  the  third  letter  m  the  representations 
name  is  B,  (e.g.  rcB,)  the  ALS  itself  will  return  a  binding  list,  which 
the  lookup  subroutine  will  n  tarn.  For  these  r?b  relations,  a  subsequent 
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M  (e.g.  rebM,)  means  the  ALS  returns  a  li«t  of  binding-lists,  rather 
than  just  one,  ThL~  4th  letter,  M,  means  multiple  values  convention  is 
retained  for  the  RQFM  representation  (used  for  multi-functions).  Here 
the  ALS  talccs  only  the  term  part  cf  the  proposition,  and  returns  a  set  of 
values.  The  HQFM-LOOKUPS  subroutine  then  forms  ti  e  list  of  appropriate 
binding-lists.  Consider  the  Square-Root  multi-function,  which  returns 
both  the  -f  and  •  root  of  a  number.  See  Computabla*Repn  (Concept), 
repn,  re,  reb,  reba,  rq,  rqb,  rqba,  rqfm. 

contents  (contents  <t>) 

returns  a  list  of  propositions  stored  in  theory  <t>.  Only  those  facts 
stored  using  the  propositional  representation  (i.e.,  pr)  will  be  found. 

cut  (cut) 

is  a  special  control  form.  When  (cut)  is  executed,  all  other  subtasks 
of  the  enclosing  doable  or  undoable  task  are  discarded.  As  a  result, 
if  the  subtask  containing  the  (cut)  form  fails,  the  enclosing  doable  or 
undoable  subtask  will  fail  as  welL  See  doable,  undoable, 

datum  (dattia  <x>) 

returns  the  symbol  corresponding  to  the  expression  or  proposition  <x>. 

deactivate  (deactivate  <ti  >  ...  <tn  >) 

deactivates  the  named  theories.  See  theory,  activetheories,  acti* 
vate. 

def  (def  <k>  <kl>...<kn>) 

means  that  the  task  <k>  is  deEned  as  (doand  <kl>  ...  <kn>).  A 
task  can  have  more  than  one  definition,  each  one  covering  a  different  set 
of  inputs.  For  example,  the  following  propositions  define  the  factorial 
function. 

(def  (fact  01)) 

(def  (fact  km  kn) 

(-  km  1  fcp) 

(fact  kp  kq) 

(•  km  kq  kn)) 

def  object  (defobject  <naae>  <pi  >  ...  Kp^  >) 

unnsserts  all  propositions  in  pr  that  mention  <name>  and  then  asserts 
the  propositions  <pi  >,...,  <Pn  >. 

def  rule  (def  rule  <rule>  <fi  >  ...  <f^  >) 

asserts  the  rule  <rult>,  and  then  trasserts  each  meta-level  <f  ^  >,  af¬ 
ter  substituting  the  symbol  associated  with  <rule>  for  *.  A  typical 
applicatic-  b  (def rule  "(if  (a  $x)  (b  $x))  •(direction  •  for¬ 
ward)),  which  asserts  (if  (a  $x)  (b  $x))  and  traeserts  (direc¬ 
tion  p307  forward),  where  p307  is  the  proposition  symbol  assigned 
to  (if  (a  $x}  (b  $x)).  As  a  shorthand,  the  *  may  be  omitted  for 
unary  functions  like  direction.  That  is,  •(direction  forward)  could 
be  used  in  place  of  •(direction  e  forward).  See  direction  and 
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trassert. 

def theory  (def theory  <iiane>  <pi  >  ...  <pn  >  empties  the  theory  <najBc> 

and  asserts  propositions  <pi  >,. . <p^  >  into  it. 

direction  (dirtetioa  <p>  <d>) 

means  that  the  mle  whose  symbol  is  <p>  should  only  be  used  in  the 
<d>  direction,  where  <d>  is  forvaxd,  backward  or  both.  E.g.,  af« 
ter  (trstash  ’(direction  p307  forward)),  the  rule  named  by  p307 
-  say,  (if  (a  |x)  (b  $x))  ^  will  only  be  used  in  the  forward  direc¬ 
tion.  That  is,  the  f  c  subroutines  will  be  able  to  use  this  rule  in  forward¬ 
chaining  (e.g.  from  (a  19)),  but  neither  be  nor  br  will  have  access  to 
this  rule.  This  is  implemented  via  the  direction*lookup,  direction* 
•tash  and  direct ion*unst ash  subroutines.  By  default,  all  rules  can  be 
used  in  both  directions.  See  be,  br,  def  rule  and  f  c. 

disjoint  (disjoint  <x>  <y>) 

means  that  lists  <x>  and  <y>  do  not  have  any  elements  in  common. 

(disjoint  nil  $y) 

(disjoint  $x  nil) 

(if  (and  (not  (elenent  $e  $s)}  (disjoint  $1  $s)) 

(disjoint  ($e  .  $1)  $8)) 

Procedural  attachment:  truep*dis Joint.  The  lisp  file  set  must  be  loaded  from  the  mrs  directory. 

disqualified  (disqualified  <k>) 

states  that  the  task  <k>  is  disqualified.  A  task  that  is  applicable 
u  executable  unless  it  is  diaqualif  led.  The  chief  way  a  task  can  get 
disqualified  b  for  there  to  be  another  applicable  task  that  it  preferred 
to  it.  However,  this  fact  is  used  when  either  of  the  twitches  executable 
or  preferred  b  non-niL  See  applicable,  scheduler. 

dl  (rtpn  <p>  dl) 

means  that  the  proposition  <p>  should  be  represented  in  the  dl  repre¬ 
sentation,  Le.  the  dl-<x>  family  of  subroutines  will  be  used  to  stash, 
unstash,  and  lookup  <p>.  This  representation  b  particularly  useful 
for  representing  propositions  involving  non-functional  binary  relations, 
e.g.  (neighbor  trance  Switzerland).  Note  that  propositions  stored 
in  thb  way  arc  not  associated  with  any  particular  theory  and  cannot 
be  found  by  PR-ba*ed  routines  like  prfacte  or  preontente.  See  dl- 
lookup,  dl*ataeh,  dl*unstaah,  rtpn. 

dl*lookup  (dl*lookup  (<r>  <a>  <b>)} 

matches  <b>  against  each  of  the  values  stored  as  the  <r>  property  of 
the  Ibp  atom  <a>,  and  if  successful  retuxns  the  resulting  binding  Ibt. 
Both  <r>  and  <a>  must  be  atoms.  See  dl. 

dl*lookup8  (dl*lookupe  (<r>  <a>  <b>)} 

matches  <b>  against  each  of  the  values  stored  as  the  <r>  property 
of  the  Ibp  atom  <a>,  and  returns  a  Ibt  of  the  binding  Ibts  for  every 
successful  match.  Both  <r>  and  <a>  must  be  atoms.  See  dl. 


The  Complcat  Guide  to  MRS 


dl-«taoh 


dl-unstash 


doable 


domain 


edtmit 


element 


(dl*jitaah  (<r>  <a>  <b>)) 

addi  <b>  to  the  list  of  value#  etored  aji  the  <r>  property  of  the  atom 
<a>.  Both  <r>  and  <a>  must  be  atoms.  Sec  dl. 

(dl^unatasb  (<r>  <a>  <b>)) 

remove*  <b>  from  the  list  of  value*  stored  aa  the  <r>  property  of  <a>. 
Both  <r>  and  <a>  must  be  atoms.  See  dl. 

ia  short  for  disjunctive  form.  A  proposition  is  in  disjunctive  form  if  it  b 
written  aa  a  disjunction  of  conjunctions  of  literals,  i.e.  atomic  propoaU 
iions  or  negations  of  atomic  propositions.  For  example,  the  proposition 
(or  (and  a  b)  (and  e  d))  is  in  disjunctive  form.  This  also  serves  as 
a  representation.  See  repn. 

(doable  <k>) 

designates  the  task  of  tiybg  to  execute  the  task  <k>.  The  task  (doable 
<k>)  succeeds  if  there  is  a  successful  execution  of  <k>.  However,  after 
a  smgle  success,  all  other  subtasks  of  <k>  are  discarded,  and  so  it  can 
succeed  at  most  once.  Note  that  as  a  result  of  the  current  implementa¬ 
tion,  it  is  not  possible  to  bterleave  subtasks  outside  a  doable  task  with 
those  inside.  See  succeed  and  cut. 

(doall  <x>  <k>  <a>) 

designates  the  task  of  gettbg  all  <x>  for  which  the  task  <k>  succeeds. 
It  packages  these  bto  a  list  and  succeeds  if  the  resultbg  list  unifies  with 
<a>. 

(doand  <ki  >  . . .  <kn  >} 

designates  the  task  of  executbg  tasks  <ki  >,. .  ^  >  m  sequence.  If 

one  of  the  tasks  can  be  executed  b  more  than  one  way,  separate  subtasks 
are  set  up  for  each  possibility.  The  doand  task  succeeds  if  there  is  at  least 
one  succesful  execution  of  all  the  tasks  b  the  list.  For  example,  (doand 
(aenlist  kx  ((a)  b  (c)))  (atoa  ix  t))  succeeds  because  the  atom 
task  succeeds  for  the  execution  of  the  sea  task  b  which  kx  b  bound  to  b. 
The  order  m  which  subtasks  are  executed  can  be  influenced  by  makbg 
appropriate  preferred  statements. 

(doaain  <ral>  <i>  <set>) 

provide  typbg  information,  bdicatbg  that  the  <i>th  argument  of  the 
relation  (or  operation)  <rtl>  must  belong  to  the  set  <set>.  E.g. 
(doaain  stash  1  propositions).  See  arity,  charactiatic,  theo* 
rito,  teras,  propositions. 

(door  <ki  >  >) 

designates  the  task  of  trybg  to  execute  one  the  tasks  <k|  <k,»  >. 

(edunit  <x>)  allows  the  user  to  edit  the  propositions  about  <z> 
usbg  ZweL  AVAILABLE  ONLY  IN  ZETALISP. 

(elaaent  <x>  <b>) 

means  that  object  <x>  b  an  element  of  Ibt  <s>. 
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(element  $e  ($e  .  $1)) 

(if  (element  $e  $1)  (elcsscnt  $a  ($7  .  tl))) 

Procedural  attacluncnt:  truep-elcment.  The  ILsp  file  f«t  must  be  loaded  from  the  mm  directory. 

•leaentain  (eleaeataiii  <b>  <•>) 

meaxu  that  <8>  it  the  set  of  all  elements  In  the  bag  <b>. 

(elementain  nil  nil) 

(if  (and  (not  (element  !•  $1))  (•lenentsin  $1  $i)) 

(elementain  ($e  .  $1)  ($e  •  ta}}) 

(if  (and  (element  $•  $1)  (tlesentaiii  $1  $•}) 

(elementain  ($e  .  $1)  $•)) 


Procedural  attachment:  truep*  element  a  In.  The  lisp  £le  aet  must  be  loaded  from  the  mm  directory. 


empty 


exdiap 


executable 


executable 


(empty  <t>) 

unasaerta  all  the  facta  in  the  theory  <t>.  Only  those  facta  atored  using 
the  propositional  representation  (i.e.,  pr}  will  be  found. 

(exdiap  <1>  <al>) 

performs  one  step  in  the  execution  of  the  list  of  tasks  <1>.  The  alist 
<al>  is  a  list  of  variable  bindings  obtained  so  far. 

(executable  <k>) 

states  that  the  task  <k>  is  executable.  If  the  value  of  the  variable 
executable  ia  non-nil,  scheduler  uses  trtruep  to  find  a  task  <k> 
auch  that  (executable  <k>}  ia  true.  If  the  value  of  executable  is 
nil,  it  simply  selects  an  element  from  the  value  of  the  variable  agenda. 
If  the  value  of  the  variable  preferred  ia  nil,  it  takes  the  fimt  element; 
otherwise,  it  uses  trtruep  to  find  the  best  according  to  the  preferred 
relation.  See  ecbeduler. 

t 

See  definition  of  the  met^Ievel  executable 


execute 


executed 


executed 


(execute  <k>) 

tries  to  execute  the  task  <k>  and,  if  successful,  returns  a  binding  list 
for  the  meta*level  variables  in  <k>.  It  is  implemented  using  exdisp. 
See  task,  def ,  doable,  undoable,  dotll,  doand,  door,  succeed,  cut, 
preferred,  tracetask. 

(executed  <k>) 

means  that  the  task  <k>  has  been  executed.  If  the  value  of  the  variable 
executed  is  non-nil,  scheduler  will  use  trassert  to  record  this  fact  of 
each  task  as  it  is  performed.  See  scheduler. 

See  definition  of  the  meta-level  executed. 


executes  (executes  <p>) 

tries  to  execute  the  task  <k>  and,  if  succettful,  returns  a  list  of  all 
bbding  lists  for  the  meta-level  variables  in  <k>.  It  is  implemented 
using  exdisp.  See  task,  def,  doable,  undoable,  dotll,  doand,  door, 
succeed,  cut,  preferred,  tracetask. 
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fc 


fcdlsp 


U 


i 


f«-lookup 


f«*Iookup8 


fta 


(fc  <p>) 

means  that  proposition  <p>  Li  assert  and  then  all  nilet  with  <p>  in  the 
premise  are  checked  to  see  if  the  premise  is  true  and  if  so  the  consequence 
is  asserted.  Only  base-level  variables  are  treated  at  variables  by  fc, 
and  any  meta*!evel  variables  are  treated  as  constants.  The  inference 
procedure  used  b  forward  chaining,  but  there  are  also  built-in  procedural 
attachments  for  many  propositions  (specified  via  the  toassert  relation). 
Fc  is  implemented  using  the  subroutbe  fcdlsp.  See  fcdlsp,  scheduler. 

(fcdlsp  <p>} 

performs  one  forward  chaining  step  on  the  proposition  <p>.  Fcdlsp 
first  calls  trtruep  to  find  a  procedural  attachments  for  <p>  other  than 
f  c,  and  if  successful  calls  that  subroutine.  Otherwise,  it  generates  other 
assertions  by  looking  in  the  data  base  for  propositions  of  the  form  (if 
<p>  <q>)  and  (if  (and  ...  <p>  ...)  <q>).  The  order  in  which 
multiple  fcdlsp  tasks  are  executed  can  be  influenced  via  appropriate 
preferred  propositions.  Fcdlsp  caches  all  results  and  saves  justifica- 
tioni  as  appropriate.  See  trtruep,  toassert,  justify. 

(repa  <p>  ft) 

means  that  the  proposition  <p>  should  be  represented  in  the  ft  rep* 
rcsentation.  That  is,  the  f  t*<x>  famUy  of  subroutbes  will  b«  used  to 
retrieve  <p>.  Its  lockup  method,  f  t*lookup,  takes  as  its  argument  a 
proposition  of  the  form  (<f>  <xi  >  ...  <Xn  >  <Xn^i  >).  It  first 
evaluates  the  term  (<f>  <xi  >  ...  <Xn  >)  by  applybg  LISP  sub¬ 
routbe  correspondbg  to  the  function  symbol  <f  >»  (Le.,  on  <f  >s  LISP 
property,]  to  the  list  obtabed  by  callbg  lookupval  on  each  of  the  <x,*  >. 
Fe-*Lookup  then  unifies  this  value  with  (lookupval  >),  and  re¬ 

turns  the  result.  See  computable-repn,  f e*lookup,  ft<*lookups,  fea, 
f q,  funproc,  rtpn. 

(fo*lookap  <p>) 

is  used  to  retrieve  the  proposition  <p>.  See  f  t|  lisp. 

(f«*lookups  <p>) 

is  functionally  equivalent  to  (pluralixa  (Fe-lookup  p)}.  See  fe,  fe-> 
lookup. 

(repa  <p>  fea) 

means  that  the  proposition  <p>  should  be  represented  in  the  fea  rep¬ 
resentation.  That  is,  the  f  •a-<x>  family  of  subroutbes  will  be  used 
to  retrieve  <p>.  Its  lookup  method,  f  ea-lookup,  takes  at  iu  argument 
a  proposition  of  the  form  (<f>  <xi  >  ...  >  <x,*.^|  >).  It  fixst 

evaluates  the  term  (<f>  <X|  >  **.  <Xn  >)  by  applybg  LISP  tub- 
routbe  correspondbg  to  the  function  symbol  <f  >,  (Le.,  on  <f  >s  LISP 
property,)  to  the  list  obtabed  by  callbg  lookupval  on  each  of  the  <x,'  >. 
Fea*Lookup  then  compares  this  value  to  (lookupval  <Xn^i  >)  usbg 
and  returns  the  result.  (Ft* lookup  just  uses  unifyp  to  produce 
this  comparison.)  See  coaputablt^repn,  fea-lookup,  fea-lookups, 
ft,  funproc,  rtpn. 
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f  ea-loolcup 


fea*lookups 


finderrors 


fq^lookup 


fq-lookupt 


function 
funproc  (2) 


funproc  (3) 


(fot-lookup  <p>) 

i*  used  to  try  to  retrieve  the  proposition  <p>.  See  f  ea,  nua-*,  lisp, 
(fea-lookupa  <p>) 

it  functionally  equivalent  to  (pl;iralize  (Fta*lookup  p)}.  See  fea, 
f *a-lookup. 

(findtrrors) 

run*  through  all  the  test  file*  to  And  the  error*  in  MRS.  For  each  error  it 
find  it  prints  out  the  result  and  expected  result.  It  returns  the  number 
of  eiTors  it  finds 

(rtpa  <p>  fq) 

means  that  the  propoaition  <p>  should  be  represented  in  the  fq  rep¬ 
resentation.  That  is,  the  f  q-<x>  family  of  subroutines  will  be  used  to 
retrieve  <p>.  By  default,  most  functions,  (including  arithmetic  ones,) 
use  this  representation.  Its  lookup  method,  f  q-lookup,  takes  as  its  ar¬ 
gument  a  proposition  of  the  form  (<f>  <xi  >  ...  <x,»  >  <Xn^i  >). 
It  first  evaluates  the  term  (<f>  <Xi  >  ...  <x,i  >)  by  applying  LISP 
subroutine  corresponding  to  the  function  symbol  <f>,  (i.e.,  on  <f>8 
LISP  property,)  to  the  list  <Xi  >  . . .  <Xn  >.  Fq-Lookup  then  unifies 
this  value  with  >,  and  returns  the  result.  See  computable-repn, 

f e,  fq* lookup,  f q*lookups,  f  qm,  rtpn. 

(fq*lookup  <p>) 

is  used  to  try  to  retrieve  the  proposition  <p>.  See  f  q  lisp, 
(fq-lookupa  <p>) 

is  functionally  equivalent  to  (plurilizt  (Fq*lookup  p)).  See  fq,  fq- 
lookup. 

(function  <x>) 

means  that  <x>  is  a  function.  See  ainglep 
(funproc  <sya>  <op>} 

means  that  the  operator  <op>  is  procedurally  attached  to  the  symbol 
<•!»>•  E.g.  after  asserting  (funproc  ♦  plus),  (lookupval  (>2  3 
4))  will  pass  2,  3  and  4  to  the  LISP  procedure  plus,  and  return  its 
answer,  0.  Note  that  this  looking-up  mechanism  is  (intentionally)  very 
simple  -  while  (lookup  (♦  2  3  4  $a))  will  work  (returning  a  bind¬ 
ing  list  which  includes  ($a  .  9),)  both  (lookup  (♦  2  3  $b  0)}  and 
(lookup  (♦  $d  0  $c))  will  return  nil.  The  (funproc  <sya>  <op>) 
aseertion  will  use  f unproc-aseert  to  forward  chain  to  assert  (function 
<syn>),  and  that  all  proposition*  (and  terms)  whose  relation  symbol 
M  <sy»>  should  use  the  f q  representation.  See  f q,  function,  funproc 
(3),  funproe-assert,  relnproc. 

(funproc  <syB>  <op>  <repn>) 

This  is  an  embellishment  of  the  binary  funproc,  listed  under  funproc 
(2).  After  a  (funproc  ^  plus)  assertion,  both  (lookup  (♦  2  (<t>  3 
4)  tx))  and  (lookup  (♦  2  3  4)  9.0))  wOlfaU-Le.  return  nil.  One 
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fuaproc-assert 

getbdg 

getbdgs 

getval 

getvals 

getvar 


ground 

groundp 

if 

iff 

includes 

includes 


can  use  the  (optional)  third  argument,  <repn>,  tc  permit  two  other, 
more  elaborate  forms  of  functional  procedural  attachment.  The  (fun- 
proc  ♦  plus  FE)  assertion  handles  the  first  problem.  Now  each  em¬ 
bedded  ground  term  -  here  2  and  (♦2  3)-  will  first  be  iookupvalcd, 
and  the  result  passed  to  the  LISP  procedure  plus.  That  is,  this  uses 
the  ft  repre^!^ntation,  rather  than  fq.  The  assertion  (funproc  ♦  plus 
F£A)  solves  the  second  problem,  causing  (♦  .  &x)  to  use  the  fea  rep¬ 
resentation.  The  <repn>  term  defaults  to  f  q  if  omitted.  One  can  also 
substitute  EVAL  for  ft,  or  «  for  fea.  See  fea,  f  e,  fq,  function,  funproc 
(2),  funproc-^assert,  bua-«,  xtlnproc. 

(funproc-assert  (funproc  <sym>  <op>  <repn>}) 
asserts  the  proposition  (funproc  <S7m>  <op>  <repn>).  (The  same 
subroutine  is  used  to  assert  (funproc  <sya>  <op>).)  See  funproc. 

(getbdg  <r>  <p>) 

is  equivalent  to  (gstvar  <v>  (truep  <p>)). 

(getbdgs'  <v>  <p>) 
is  equivalent  to 

(aapcar  (laabda  (1)  (getvar  <v>  1))  (truepa  p)}. 

(getval  (<r>  <xi  >  ...  <Xn  >)) 

is  equivalent  to  (getbdg  <y>  (<r>  <xi  >  ...  <Xn  >  <y>)). 
(getvals  (<r>  <Xi  >  ...  <x„  >)) 

is  equivalent  to  (gstbdgs  <y>  (<r>  <Xi  >  ...  <Xn  >  <y>)). 
(getvar  <v>  <1>) 

looks  up  the  bbding  of  the  variable  <t>  on  the  binding  list  <1>,  fully 
instantiates  it  with  respect  to  the  other  variables  on  <1>«  and  returns  the 
result.  For  example,  (getvar  $x  (($x  .  (f  $y))  ($y  .  a)))  would 
return  (f  a). 

(ground  <x>} 

states  that  the  expression  <x>  is  a  ground  expression,  i.e.  it  contains 
no  variables.  See  lookup-ground. 

(groundp  <x>) 

returns  t  if  and  only  if  the  expression  <x>  contains  no  variables. 

(if  <p>  <q>) 

means  that  whenever  proposition  <p>  is  true,  proposition  <q>  is  true. 
See  be,  br,  f  c. 

(iff  <p>  <q>) 

is  equivalent  to  (and  (if  <p>  <q>)  (if  <q>  <p>)). 

(includes  <c>  <d>) 

means  that  the  theory  <c>  includes  the  theory  <d>, 

(includes  <tx  >  <ta  >) 

makes  theory  <ti  >  a  supertheory  of  theory  <t3  >  so  that  whenever 
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<ti  >  Is  active  <t3  >  will  be  active  as  well.  In  effect  theory  <ti  > 
includes  all  of  the  propositions  in  <13  >.  Both  theory  and  activethe- 
ories  take  these  inclusions  into  account. 

indb  (indb  <p>) 

indbp  (indbp  <p>) 

means  that  a  proposition  equal  to  <p>  up  to  variable  renaming  is  stored 
in  the  pr  representation.  See  pr*indbp. 

Integer  (Integer  <x>) 

means  that  <x>  is  an  integer. 

inter  (inter  <x>  <y>  <b>) 

means  that  list  <b>  is  every  element  in  list  <x>  that  is  in  list  <y>. 

(inter  nil  $y  nil) 

(if  (and  (element  $•  $y)  (inter  $1  $y  Ss}) 

(inter  ($e  .  $1)  $y  ($e  .  Is))} 

(if  (and  (not  (element  |e  ly))  (inter  $1  $y  Is)) 

(Inter  ($e  .  |1)  |y  Is)) 

Procedural  attachment;  traep*inter.  The  lisp  file  set  must  be  loaded  from  the  mrs  directory. 

intersect  (intersect  <x>  <y>) 

means  that  bag  <x>  and  bag  <y>  have  an  equal  element. 

(if  (or  (element  |e  Is)  (intersect  |1  Is)) 

(intersect  ($e  .  |1)  Is)} 

Procedural  attachment:  truep- intersect.  The  lisp  file  set  must  be  loaded  from  the  mrs  directory. 

is  (is  <x>  <y>) 

means  that  the  value  of  the  arbitrarily  nested  expression  <x>  is  <y>. 
See  lookup-is,  truep-is. 

Just  (Just  <q>  <tt>  <pi  >  ...  <pn  >) 

means  that  the  justification  for  the  proposition  named  <q>  is  the  infer¬ 
ence  method  <a>  and  the  premises  <pi  >, ...  <pn  >.  See  where,  why, 
Justify,  ta-unassert. 

Justify  is  a  variable  govemmg  MRSs  mechanism  for  recording  justifications. 

When  nouNIL,  its  value  is  the  name  of  the  theory  into  which  MRS  will 
save  justifications  for  all  deductions.  (If  Justify  has  the  value  T,  then 
the  current  theory  is  used.)  It  is  recommended  that  one  house  these 
propositions  in  a  temporary  theory,  and  apply  empty  to  this  theory  when 
these  justifications  are  no  longer  needed.  See  why  and  where. 

kb  (kb  to<g>  <argt  >  ...  <arg;^  >) 

is  MRSs  way  of  handling  procedural  attachments.  It  is  equivalent  to 
(apply  (getvar  ki  (trtruep  (to<g>  <argi  >  ...  <arg;/  >  ki) 
<argi  >  ...  <arg//  >)).  See  to<g>. 

known  (known  <p>) 

means  that  proposition  <p>  must  be  in  the  database  for  this  to  be  true. 
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See  unla30\m. 

length  (length  <1>  <a>) 

meanj  that  the  list  <1>  b  of  length  <n>. 

Ihfalse  (Ihfalee  (improvable  <p>)) 

calls  lookup  on  the  proposition  <p>.  It  returns  ail  if  the  answer  is 
non»nil;  otherwise,  it  returns  truth. 

Ihtrue  (Ihtrue  (provable  <p>}) 

calls  lookup  on  the  proposition  <p>  and  returns  the  answer. 

lisp  (lisp  <s7m>  <op>) 

means  that  <op>  is  the  Lisp  subroutine  used  to  compute  the  function 
denoted  by  the  symbol  <Bym>.  E.g.  (lisp  ♦  plus).  See  Computable* 
Repn  (Concept),  lea-lookup,  f e-lookup,  fq-lookup,  rt-lookup,  rq- 
lookup,  rqb-lookup,  reb-lcokup,  rqfa-lookups. 

lookup  (lookup  <p>) 

checks  whether  the  proposition  <p>  matches  a  proposition  in  the  data 
base  and,  if  so,  returns  the  correponding  binding  list.  Lookup  is  an 
abstract  operator  implemented  using  kb  and  tolookup. 

lookup—  (lookup—  (•  <x>  <y>)) 

calls  unifyp  on  the  expressions  <x>  and  <y>  and  returns  the  result. 
See  •. 

lookup-bagof  (lookup-bsgof  (begof  <x>  <p>  <s>)) 

calls  lookups  on  <p>  and  matches  <s>  against  the  sequence  formed 
by  plugging  the  answers  into  <x>.  Lookup-bagof  is  useful  for  perform* 
ing  exteniional  reasoning,  since  it  allows  one  to  designate  the  set  of  all 
solutions  to  a  problem. 

lookup-ground  (lookup-ground  (grotmd  <x>)) 

returns  ((t  p  t))  if  and  only  if  the  expression  <x>  contains  no  vari¬ 
ables.  See  ground. 

lookup-is  (lookup-is  (is  <x>  <y>)) 

uses  lookupval  to  evaluate  the  arbitrarily  nested  expression  <x>  and 
tries  to  unify  the  answer  with  <y>.  See  is.  . 

lookupapplicable  (lookupapplicablo  (applicable  <k>)) 

tries  to  match  <k>  with  each  element  of  agenda  and  returns  a  corre¬ 
sponding  binding  list  if  successfoL  See  applicablo. 

lookupbdg  (lookupbdg  <t>  <p>} 

is  equivalent  to  (getvar  <v>  (lookup  <p>}). 

lookupbdgs  (lookupbdgs  <v>  <p>} 

is  equivalent  to  (aapear  (lambda  (x)  (getvar  <v>  x))  (lookups 
<p>)). 

lookupby lookups  (lookupbylookups  <p>) 

is  equivalent  to  (singularixs  (lookups  <p>)}. 
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‘  lookups  (lookups  <p>) 

checks  whether  the  proposition  <p>  matches  any  propositions  in  the 
data  base  and  returns  a  list  of  binding  lists  for  each  successful  match. 
Lookupa  is  an  abstract  operator  implemented  using  kb  and  tolookupa. 


lookupsapplicable  (lookupsappllcabl®  (appllcabla  <k>)) 

tries  to  match  <k>  with  each  element  of  agenda  and  returns  list  of 
binding  lists  for  each  successful  match.  See  applicable. 

lookup sby lookup  ( lookup abylookup  <p>) 

is  equivalent  to  (pluxalixe  (lookup  <p>)). 

lookupval  (lookupval  (<f>  <xi  >  ...  <Xn  >)) 

is  equivalent  to  (getvar  <y>  (lookup  (<i>  <xx  >  ...  <Xn  > 

<y»)). 


lookupvala  (lookupvala  (<f>  <xi  >  ...  <x«  >)) 

is  equivalent  to  (aapcar  (lambda  (x)  (getvar  <y>  x))  (lookupa 
(<f>  <xi>...<Xn>  <y>))). 

aand  (amnd  <p>  <1>) 

if  aatisfled  if  (<p>  x)  is  true  for  every  x  in  the  list  <1>. 

(aand  $p  nil) 

(if  (and  ($p  $x)  (aand  $p  $1)) 

(aand  $p  ($x  .  $1)}) 


Procedural  attachment:  truep*aand.  The  lisp  flle  set  must  be  loaded  fxt>m  the  mrs  directory. 

nandcan  (aandcan  <p>  <1>  <■>) 

means  that  <a>  is  the  union  of  the  lists  y  that  satisfy  (<p>  x  y)  for 
every  element  x  in  list  <1>. 

(aandcan  ti  nil  nil) 

(if  (and  ($f  $x  $y)  (aandcan  $f  |1  $s)  (union  $y  $•  $t)} 

(aandcan  $f  ($x  .  $1)  $t)) 


Procedural  attachment:  truep-aandcaa.  The  lisp  fie  set  must  be  loaded  from  the  mrs  directory. 

aandcar  (aandcar  <p>  <1>  <a>) 

means  that  <s>  is  the  set  of  objects  y  that  satisfy  (<p>  x  y)  for  every 
element  x  in  list  <1>. 


(aandcar  $f  nil  nil) 

(if  (and  ($f  $x  ly)  (aandcar  If  $1  Is)) 

(aandcar  If  (lx  .  II)  (ly  .  Is)}) 

Procedural  attachment:  truep-aapcar.  The  lisp  file  set  must  be  loaded  from  the  mrs  directory. 

aatchp  (aatchp  <x>  <y>) 

checks  whether  the  expressions  <x>  and  <y>  can  be  unified  by  some 
set  of  bindings  for  the  meta-level  variables  in  the  two  expressions.  If  so, 
aatchp  returns  the  corresponding  binding  list  for  the  variables  in  <x> 
but  discards  the  bindings  for  the  variables  in  <y>.  If  the  expressions 
are  not  unifiable,  aatchp  returns  nil.  All  variables  in  <x>  are  treated 
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mem 


member 


memlist 


mlvarp 


mraapropoB 

mxademo 

mxade scribe 
nr 8 dump 

mrsLelp 

mrsload 

mrasave 

mrat of unctions 

not 


as  dbtinct  from  the  variables  in  <7>i  even  though  they  have  the  same 
name.  For  example,  the  expression  (r  kx  b)  matches  (r  a  kx)  with 
ifsult  (Ux  .a)  (t  p  t)).  See  batchp. 

(mea  <t>  <c>) 

means  that  the  element  <e>  is  a  member  of  the  set  of  <c>.  E.g.,  (mea 
gaorge  people).  See  aubclasa. 

(member  <a>  <a>} 

means  that  <a>  is  a  member  of  the  list  <s>,  e.g.  (aember  S  (4  5 

6)). 

(memlist  <x>  <1>) 

designates  the  task  of  checking  whether  the  object  <x>  is  in  the  list  <1>. 
Kemlist  tries  to  unify  <x>  with  ecxh  element  of  <1>  and  succeeds  once 
for  each  match  that  it  finds. 

(mlvarp  <xp>) 

returns  a  non-nil  value  if  <xp>  is  a  meta^Ievel  variable  and  otherwise 
returns  nil.  A  meta-variable  in  MRS  is  denoted  by  an  ampersand  prefix 
(k)  and  is  intemaUy  distinguished  by  the  value  ml,  e.g.  ki  is  a  meta-level 
variable.  See  varp. 

(mrsapropos  <■>) 

returns  a  list  of  all  LISP  atoms  containing  <s>  as  a  substring  of  their 
printnames. 

(mrsdemo) 

presents  a  demonstraticn  of  the  range  of  capabilities  in  MRS. 
(mrsdescribe  <x>) 

prints  out  the  portion  of  this  dictionary  relevant  to  the  object  <x>. 
(mrsdiimp  <t>  <1>) 

saves  the  propositions  from  theory  <t>  in  a  form  that  allows  them  to 
be  reloaded  with  LISPs  load  command.  Only  those  facts  stored  using 
the  propositional  representation  (i.e.,  pr)  will  be  found. 

(mrshelp  <k>)  provides  information  about  the  MRS  keyword  <k>. 

(mrsload  <f>) 

loads  a  file  <f  >  of  propositions. 

(mrasave  <ti  >  ...  <tn  >  <f>) 

saves  the  propositions  from  theories  <tx  >  . . .  <tn  >  in  the  file  <f  >  in  a 
form  that  allows  them  to  be  reloaded  with  the  mrsload  command.  Note 
that  this  works  only  for  propositions  stored  in  the  pr  representation. 

refers  to  the  set  of  all  MRS  to<g>  functions  -  e.g.  (mem  tostash 
mrat  of  unctions).  See  domain. 

(not  <p>) 

means  that  the  proposition  <p>  is  false.  This  is  not  equivalent  to  un* 
known,  or  to  unprovable. 
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num-*  (nnm-"  <x>  <y>> 

means  that  the  expressions  <x>  and  <y>  are  ntimcrically  equal  -  or 
close  enough  to  qualify.  Proced orally,  if  <x>  and  <y>  (are  nonNIL 
and)  unify,  that  MGU  value  is  returned.  Otherw-'ise,  if  both  terms  are 
ground  atomic  numeric  expressions,  whose  diflfcrence  is  less  than  NUM- 
—  jTHRFSHOLD,  truth  is  returned.  E.g.  (nua-*  3  3.0)  returns  truth, 
whereas  (unifyp  3  3.0)  returns  nil.  See  lea,  mm— the sho Id. 

nu!n-“-  threshold  ii  a  special  variable  whose  value  is  the  tolerance  required  for  two  numeric 
values  to  be  considered  equal.  It  is  initially  set  to  0.0001.  See  ntiffl-*- 

number  (number  <x>) 

means  that  <x>  is  a  nura'^c^. 

(or  <pi  >  . . .  <pn  >) 

means  that  one  or  more  of  the  propositions  <pi  >  . . .  <pn  >  is  true, 
(output  <x>) 

translates  the  expression  <x>  into  pseudo-natural  language  in  accor¬ 
dance  with  programmer-deflned  templates.  See  template. 

(pattern  <d>) 

returns  the  proposition  corresponding  to  the  proposition  symbol  <d>. 

perceive  (perceive  <p>) 

determines  whether  the  proposition  <p>  is  true  by  direct  observation 
rather  than  inference.  Perceive  is  an  abstract  operator  implemented 
using  kb  and  toperceive. 

perceive-indb  (perceive-indb  (indb  <p>)) 

perceivc-not  (purceive*not  (not  <p>)) 

perceives  (perceives  <p>) 

determines  whether  the  proposition  <p>  is  true  by  direct  observation 
rather  than  inference  and  returns  a  list  of  all  binding  lists  for  which  it 
succeeds.  Perceives  is  an  abstract  operator  implemented  using  kb  and 
toperceive  s. 

pi  (repn  <p>  pi) 

means  that  the  proposition  <p>  should  be  represented  in  the  pi  repre¬ 
sentation,  i,e.  the  pl-<x>  family  of  subroutines  will  be  used  to  stash, 
unstash,  and  lookup  <p>.  This  representation  is  particularly  useful  for 
representing  propositions  involving  unary  functions,  e.g.  (arity  mem¬ 
ber  2).  Note  that  propositions  stored  in  this  way  are  not  associated 
with  any  particular  theory  and  cannot  be  found  by  PR-based  routines 
like  prf acts  or  preontents.  See  pl-lookup,  pl-staab,  pl-unstash, 
repn. 

pl-lookup  (pl-lookup  (<i>  <a>  <b>)) 

matches  <b>  against  the  <f>  property  of  the  lisp  atom  <a>.  <f>  and 
<a>  must  both  be  atoms.  See  pi. 
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pi  "fltaflh 


pi  unstash 


plug 


pluralize 


pr-indbp 


pr-lookup 


pr-lookups 


pr-stash 


pr^-unstash 

prcontents 


preferred 


(pl-»taah  {<f>  <a>  <b>)) 

places  <b>  on  the  property  list  of  <8>  under  the  indicator  <f  >.  <f  > 
and  <a>  must  both  be  atoms.  See  pi. 

(pl-unstaah  (<f>  <a>  <b>)) 

removes  the  <f  >  property  from  the  lisp  atom  <a>,  if  its  value  was  <b>. 
<f  >  and  <a>  must  both  be  atoms.  See  pi. 

(plug  <x>  <1>) 

returns  a  copy  of  the  expression  <x>  fully  instantiated  with  respect  to 
the  variables  on  the  binding  list  <1>.  For  excjnple,  (ping  (r  $x  $z) 
(($x  .  (f  $y))  ($y  .  a}))  would  return  (r  (f  a)  $z). 

(pluralize  <x>) 

returns  the  plural-value  of  <x>.  That  is,  it  returns  (liet  <x>)  if  <x> 
is  nonNIL,  or  nil  otherwise.  See  lookupsbylookup,  truepsbytruep. 

(repn  <p>  pr) 

means  that  the  proposition  <p>  should  be  represented  in  the  pr  repre¬ 
sentation,  i.e.  the  pr-<x>  family  of  subroutines  will  be  used  to  stash, 
unstash,  and  lookup  <p>.  This  is  MRSs  default  representation.  Propo¬ 
sitions  stored  in  this  way  can  be  associated  with  any  number  of  theories 
and  will  be  available  for  use  only  when  one  or  more  of  those  theories  are 
active.  Sec  pr-lookup,  pr-indbp,  pr-atash,  pr-unstash. 

(pr-indbp  <p>) 

checks  whether  there  u  a  proposition  in  the  pr  representation  that  is 
identical  to  <p>  up  to  variable  renaming  and,  if  so,  returns  its  proposi¬ 
tion  symbol.  See  pr. 

(pr-lookup  <p>) 

uses  indexp  and  batchp  to  find  any  matching  proposition  in  the  pr 
representation  and,  if  successful,  returns  the  corresponding  binding  ILt. 
See  pr. 

(pr-lookupa  <p>) 

uses  indexp  and  batchp  to  find  any  matching  proposition  in  the  pr  rep¬ 
resentation  and  returns  a  list  of  all  binding  lists  for  which  it  is  successful. 
See  pr. 

(pr-stash  <p>) 

stores  <p>  in  the  propositional  data  base  and  returns  the  corresponding 
proposition  symbol.  See  pr. 

(pr-unata*h  <p>) 

removes  the  proposition  <p>  from  the  propositional  data  base.  See  pr. 
(prcontents  <th>) 

prints  out  all  propositions  in  theory  <th>.  Only  those  facts  stored  using 
the  pr  representation  will  be  found. 

(preferred  <j>  <k>) 

states  that  the  task  <j>  is  preferred  to  the  task  <k>.  The  preferred  is 
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prfacta 


primitive 


property 

prepositions 


provable 


re 


re-lookup 

re-lookups 

reb 


important  in  that  <k>  if  difqnalifled  whenever  there  is  an  applicable 
task  that  is  preferred  to  it.  This  relation  U  the  primary  way  of  inSu- 
cncinj;  task  ordering  in  MRS.  It  baa  effect  only  when  one  of  the  switches 
executable  or  preferred  has  a  non  null  value.  See  diaqualif led, 
scheduler. 

(prfacts  <n>) 

prints  out  all  propositions  about  <n>  in  the  cxorently  active  theories. 
Only  those  facts  stored  using  the  pr  representation  will  be  found. 

(primitive  <k>) 

states  that  the  operator  in  the  task  <k>  is  a  primitive  machine  operation, 
i.e.  a  Lisp  subroutine. 

(property  <x>  <y>  <z>) 

means  that  the  atom  <x>  has  <y>  as  its  <z>  property. 

(domain  <x>  <i>  propositions) 

means  that  the  <i>th  argument  to  the  subroutine  <x>  should  be  a 
proposition.  See  domain. 

(provable  <p>) 

means  that  proposition  (provable  <p>)  is  true  if  <p>  can  be  proved 
using  the  normal  mechanisms  for  proving  <p>.  See  unprovable. 

(repn  <p>  re) 

means  that  the  proposition  <p>  should  be  represented  in  the  re  rep* 
resentation.  That  is,  the  rt-<x>  family  of  subroutines  will  be  used  to 
retrieve  <p>.  Its  lookup  method,  re-lookup,  takes  as  its  argument  a 
proposition  of  the  form  (<r>  <Xi  >  ...  <Xn  >)  ind  calls  lookupval 
on  each  of  the  <x^  >.  If  there  is  a  LISP  subroutine  (i.e.  on  <r>8 
LISP  property,)  corresponding  to  the  relation  symbol  <r>,  re-lookup 
applies  the  subroutine  and  returns  ((t  p  t)}  if  that  subroutines  re¬ 
turns  nonNIL;  otherwise  it  return  nil.  See  conputable-repn,  repn, 
rt-lookup,  re-lookups,  rq,  reb,  relnproc. 

(rt-lookup  <p>) 

is  used  in  trying  to  retrieve  the  proposition  <p>.  See  re. 

(re-lookups  <p>) 

is  functionally  equivalent  to  (plurilizt  (Re-lookup  p)).  See  re,  re- 
lookup. 

(repn  <p>  reb) 

means  that  the  proposition  <p>  should  be  represented  in  the  reb  rep¬ 
resentation.  That  is,  the  reb-<x>  family  of  subroutines  will  be  used  to 
retrieve  <p>.  Ite  lookup  method,  reb-lookup,  takes  as  iU  argument  a 
proposition  of  the  form  (<r>  <xi  <Xn  >).  If  there  is  a  LISP 
subroutine  (i.e.  on  <r>s  LISP  property,)  correspondbg  to  the  relation 
symbol  <r>,  reb-lookup  applies  the  subroutine  to  these  arguments,  and 
returns  the  result  (assumed  to  be  a  binding  list).  E.g.  (repn  (unifyp 
$a  $b)  reb).  See  computable-repn,  repn,  reb-lookup,  reb-lookups. 
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reb-looJcup 


reb-lookupi 


reba 


rtbm-lookup 


rtlsproe  (2) 


relsproc  (3) 


(rtb-lockup  <p>) 

is  in  tid  ing  to  retrieve  lh«  proposition  <p>.  Se*  rtb,  rslnproc. 

(rsb^lookups  <p>) 

is  fnnctionadly  equiva^lent  to  (plurnllzs  (irtb^lookup  p}).  Se«  rtb^ 
rsb-looJojp. 

(r«pn  <p>  rtb«) 

me nns  that  the  proposition  <p>  shonld  b«  rsprtsentsd  in  tht  xsbsi  rtp* 
rcsentation.  Thnt  is,  tbs  rtba-<x>  family  of  tnbron tines  will  be  nsed 
to  retrieve  <p>.  lU  looknp  method,  reb**lookQp,  takes  as  its  argn* 
msnt  a  proposition  of  the  form  (<r>  <X|  >  •«.  <Xn  >)•  If  there  is 
a  LISP  snbrontine  (Le.  on  <x>s  LZ3P  property,)  corresponding  to  the 
relation  symbol  <x>,  xeb*  lookup  applies  the  tnbron  tine  to  these  argn- 
menu,  and  returns  the  result  (assumed  to  be  a  list  bmding  lists).  See 
ceaputibls*xepa,  xtb,  xeba-lookup,  xtb* lookups,  xtinproc,  xepn. 

(re1»i*lookup  <p>) 

is  functionally  equivalent  to  (singulaxize  (xtb^lookup  p)).  See 
xebs,  xeb*lookup. 

(xelnpxoe  <sym>  <op>) 

is  a  way  of  procednrally  attaching  the  operation  <op>  to  the  relation 
symbol  <ayB>.  E.g.  after  asserting  (xtlnpxoe  <  gxeatex^thaa), 

(lookup  (<  2  4))  will  pass  2  and  4  to  the  LISP  procedure  gxeater^ 
than,  and  seeing  iU  answer  is  nonKZt,  the  lookup  call  will  return  (  (t  p 
t)).  (It  would  otherwise  return  MIL.)  The  (xelnpxoe  <syi>  <op>) 
assertion  will  use  xelnpxoc*aaaext  to  forward  chain  to  assert  that  all 
propositions  whose  relation  symbol  is  <sys>  should  use  the  rq  rtpre* 

•entation.  See  funpxoc,  xelnpxoe  (3),  xtlnproc*assextt  xq. 

(xelnpxoe  <eyn>  <op>  <xepn>)  ^ 

There  are  various  possible  limitations  with  binary  xelnpxoe  mecha> 
nism,  listed  above  under  xelnpxoe  (2).  First,  after  asserting  (rel* 
npxee  <  greatex-than),  the  query  (lookup  (<  2  (♦  1  3)))  will  re¬ 
turn  nil.  Second,  after  asserting  (xelnpxoe  unify  unifyp),  (lookup 
(unify  (a  ly)  ($x  b)}}  will  only  return  ((t  p  t)},  ignoring  the  ($x 
.  a)  and  ($y  •  b)  bindings.  The  (optional)  third  argument  above, 

<xepn>,  permiU  other,  more  elaborate  forms  of  relational  procedural 
attachment.  The  (xelnproe  <  gxeatex-than  BE)  aesertion  handles 
the  first  problem.  Here  each  embedded  ground  term  -  here  2  and  (♦  1 
3)  -  will  first  be  leokupvaled,  and  the  result  pasted  to  the  LISP  pro¬ 
cedure  fxeatax*than.  This  uses  the  xt  representation,  rather  than  xq.  | 

The  (xelnpxoe  unify  unifyp  RQB)  assertion  handles  the  second  prob¬ 
lem,  as  the  (unify  4x  tj)  facts  wiU  now  use  the  RQB  representation. 

Similarly  <xtpn>  can  be  set  to  RQBM,  R£B,  REQB  or  RQFM.  If  omitted, 

<reptt>  here  defaults  to  xq.  One  can  also  use  the  aliases  EVAL  for  RE, 

BindLiat  for  RQB,  MBindLiat  for  REBM,  EBindLiat  for  REB,  KEBindLiat 

for  REBM,  or  KultiFa  for  RQFM.  See  xelnpxoe  (2),  relnpxoe*^aaaext,  ] 

xe,  reb,  rebn,  rq,  rqb,  xqbn,  xqfn.  | 
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rtlnproc-assert  (z«lnproc-«s#«Tt  (rtlrproc  <«]na>  <op>  <r#pa>)) 

a^^scrts  the  prcpoaitioa  (rfflcproc  <^j^>  <op>  <repa>).  (The  tame 
•ubroutiae  is  used  to  ajufcrt  (ralcproc  <«yis>  <op>).)  Seerelnproc. 

repa  (rapn  <p>  <rpa>) 

meaai  that  the  representation  <rpa>  should  be  used  to  store  and  ac¬ 
cess  the  proposition  <p>.  (See  repnt  entry  for  list  of  allowable  repre- 
eentatioas.)  See  achieve,  repa-aeeert,  lepa-sethod,  repa-aaaeeert, 
repne. 

repa-aesert  (repn*aeie:.s  (rtpa  <prop>  <rpn>)) 

uses  the  repa-aethod  declarations  sissociated  with  this  representation 
<rpn>  to  stash  (in  a  forward  chaining  manner)  the  appropriate  to<x> 
statementa  for  this  <prop>.  The  dosaia  specification  of  that  operation 
is  used  to  determine  the  exact  form  of  the  assertion.  E.g.  calling  repn** 
assert  on  the  assertion  (repa  (father  kc  ^d)  pi)  will  generate  the 
•tatemenU  (tolookup  (father  Ac  Ad)  pl-lookup),  and  (tolookupe 
(father  Ac  Ad)  pl-lookupe), as  (doaala  lookup  1  propositions). 
(Later  it  may  deal  with  terms,  and  assert  facts  like  (tolookupval 
(father  Ac)  pl-lookupval),  {via  (do&tla  lookupval  1  terms))  as 
well.)  See  domain,  rtpa,  repa-method,  repa-unassert. 

repn-aethod  (repa*method  <rpa>  <op>  <athd>) 

meaas  that  the  LISP  subroutbe  <Bthd>  should  be  used  to  perform  the 
<op>  operation,  in  the  representation  <rpn>.  E.g.  (repn^method  pr 
tostash  pr*staah).  See  repa-assert,  repa,  repn^unassert. 

repa*unassert  (repa-uaassert  (repa  <prop>  <rpa>)) 

undoes  the  effects  (read  stashes)  of  repn*assert.  See  domain,  repa, 
repa*asiert,  rtpa-aethod. 

repns  (mem  <r>  rtpas) 

meant  that  the  symbol  r  refers  to  t  representations.  Currently  existing 
representations  include  caf ,  dl,  pi,  pr,  tl  and  achieve-perceive,  all 
of  which  store  resulU;  and  f  #,  f  ta,  fq,  re,  reb,  rebm,  rq,  rqb,  rqbm  and 
rqfm  which  do  not.  See  repo,  computable*rtpn. 

residue  (residue  <p>) 

tries  to  prove  the  proposition  <p>.  It  differs  from  truep  in  that  it  is 
allowed  to  make  assume  any  proposition  asserted  to  be  assumable;  and, 
if  it  is  successful  in  proving  <p>,  it  returns  a  list  of  its  assumptions.  The 
set  of  assumptions  is  called  the  residue  of  <p>.  Residue  is  an  abstract 
operator  defined  using  kb  and  tores idue.  See  aeeuaeble. 

rteiduee  (reeidues  <p>) 

tries  to  prove  the  proposition  <p>.  It  differs  from  truepe  in  that  it  is 
allowed  to  make  assume  any  proposition  asserted  to  be  assumable;  and, 
if  it  is  successful  in  proving  <p>,  it  returns  a  list  of  lists  of  assumptions. 
The  set  of  assumptions  is  called  the  reeidue  of  <p>.  Residue  is  an 
abstract  operator  defined  using  kb  and  toresidue.  See  assumable. 
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resolution  (resolution  <p>) 

tries  to  prove  the  prcpotition  <p>.  If  successful,  it  returnj  an  appropri¬ 
ate  bbdbg  list;  othcrwbe,  it  returns  nil.  Resolution  is  an  iinplemen- 
tation  of  line  ax- input  resolution  using  the  set  of  support  control  strategy; 
In  operation,  resolution  negates  <p>  and  converts  it  to  conjunctive 
form,  stashes  the  results  in  a  locally  bound  theory,  and  invokes  the  sub- 
routine  rsdlsp  on  each  conjunct.  See  radisp,  scheduler,  tracstask^ 
cnf. 

rcfiolutlonxesidus  (resolutionresidus  <p>} 

tries  to  prove  the  proposition  <p>.  If  succesfol,  it  returns  a  list  of  aesum- 
able  propositons  which,  when  added  to  the  data  base,  imply  <p>.  Res* 
olutionrtsidut  is  an  implementation  of  linear-input  resolution  using 
the  set  of  support  control  strategy.  In  operation,  rtsolutionrtsidue 
negates  <p>  and  converts  to  conjunctive  form,  staxhes  the  results  in  a 
locally  bound  theory,  and  invokes  the  subroutine  rrdisp  on  each  con¬ 
junct.  See  rrdisp,  scheduler,  tracetask,  cn.!» 

resolutionresidue  (resolutionresldua  <p>) 

tries  to  prove  the  proposition  <p>.  If  succesful,  it  returns  a  list  of  assum¬ 
able  propositons  which,  when  added  to  the  data  base,  imply  <p>.  Rea- 
olutionrealdua  is  an  implementation  of  linear^input  resolution  using 
the  set  of  support  control  strategy.  In  operation,  reaolutlonreaidut 
negates  <p>  and  converts  to  conjunctive  form,  stashes  the  results  in  a 
locally  bound  theory,  and  invokes  the  tubreutine  rrdisp  on  each  con¬ 
junct.  See  rrdisp,  scheduler,  tracetask,  enf 

reeolutionresidues  (resolutionresiduee  <p>) 

tries  to  prove  the  proposition  <p>.  It  returns  a  list  of  all  assumption  lists 
for  which  it  it  tuccessfuL  Resolutionresidues  is  an  implementation  of 
linear-input  resolution  using  the  set  of  support  control  strategy.  In  op¬ 
eration,  resolutionresidues  negates  <p>  and  converts  to  conjunctive 
form,  stashes  the  results  in  a  locally  bound  theory,  and  Invokes  the  sub¬ 
routine  rrdisp  OB  each  conjunct.  See  rrdisp,  scheduler,  tracetask, 

CBf. 


resolutions  (resolutions  <p>) 

tries  to  prove  the  proposition  <p>.  It  returns  a  list  of  all  binding  lists 
for  which  it  is  tuccessfuL  Resolutions  is  an  implementation  of  linear- 
input  resolution  using  the  set  of  support  control  strategy.  In  operation, 
resolutions  negates  <p>  and  convtru  to  conjunctive  form,  stashes  the 
results  in  a  locally  bound  theory,  and  mvokes  the  subroutine  rsdisp  on 
each  conjunct.  See  rsdisp,  scheduler,  tracetask,  enf . 

rq  (repn  <p>  rq) 

means  that  the  proposition  <p>  should  be  represented  in  the  req  rep¬ 
resentation.  That  IS,  the  rq-<x>  family  of  subroutines  will  be  used  to 
retrieve  <p>.  Its  lookup  method,  rq-loekup,  takes  as  its  argument 
a  proposition  of  the  form  (<r>  <xi  >  ...  <x«  >).  If  there  is  a 
LISP  subroutine  corresponding  to  the  relation  symbol  <r>,  (i.e.  on 


Appendix  C:  Dictionary  of  predicatca  and  filings  105 


rq*lookup 

rq“look\ip« 

rqb 


rqb-lookup 

rqb-lookups 

rqbm 


rqbm* lookup 


rqfa 


<r>f  LIS?  property,)  rq-lookup  applic*  the  enbroutbe  to  the  argu¬ 
ments  {<Xx  >  ...  <Xn  >)t  returns  truth  if  the  result  is  noimil; 
or  nil.  By  default,  most  relations,  including  arithmetic  ones,  use  this 
representation.  See  ro,  rq- lookup,  rq-lookitpt,  relcproc,  repn. 

(rq-lookup  <p>) 

is  used  in  trying  to  retrieve  the  propoeiticn  <p>.  See  rq,  liap. 
(rq-lookupo  <p>) 

U  functionally  equivalent  to  (pluralixt  (Rq-lookup  p)).  See  rq,  rq- 
lookup. 

(repn  <p>  rqb) 

means  that  the  proposition  <p>  should  be  represented  in  the  rqb  rep¬ 
resentation.  That  is,  the  rqb-<x>  family  of  subroutines  will  be  used  to 
retrieve  <p>.  Its  lookup  method,  rqb-lookup,  tak^  as  its  argument  a 
propceitioa  of  the  form  (<r>  <Xi  >  ...  <Xn  >).  If  there  is  a  LISP 
subroutine  corresponding  to  the  relation  symbol  <r>,  {Le.  on  <r>t 
LISP  property,)  rqb-lookup  applies  the  subroutine  to  the  arguments 
(<xi  >  ...  <Xn  >}»  and  simply  returns  the  result  (assumed  here  to  be 
a  binding-list).  See  coaput  able -repn,  reb,  rqb-lookup,  rqb-lookupe, 
relnproe,  repn. 

(rqb-loolmp  <p>) 

is  used  in  trying  to  retrieve  the  proposition  <p>.  See  rqb,  rqb»,  liep. 
(rqb-lookupe  <p>) 

is  functionally  equivalent  to  (pluralize  (Rqb-lookup  p)).  See  rqb, 
rqb-lookup. 

(repn  <p>  rqbm) 

means  that  the  proposition  <p>  should  be  represented  in  the  rqbm  rep¬ 
resentation.  That  is,  the  rqbn-<x>  family  of  subroutines  will  be  used 
to  retrieve  <p>.  Its  lookup  method,  rqb-lookup,  takes  as  its  argu¬ 
ment  a  proposition  of  the  form  (<r>  <xi  >  ...  <Xn  >).  If  there  is 
a  LISP  subroutine  corresponding  to  the  relation  symbol  <r>,  (Le.  on 
<r>i  LISP  property,)  rqb-lookup  applies  the  subroutine  to  the  argu¬ 
ments  {<Xi  >  ...  <Xn  >),  and  simply  returns  the  result  (assumed  here 
to  be  a  list  of  bmdiag-lists).  See  computable-repn,  rqb,  rqbm-lookup, 
rqb-lookup,  relnproe,  repn. 

(rqbm-lookup  <p>) 

is  functionally  equivalent  to  (singularize  (Rqb-lookup  p)).  See 
rqbm,  rqb-lookup. 

(repn  <p>  rqfm) 

means  that  the  proposition  <p>  should  be  represented  in  the  rqfm  rep¬ 
resentation.  That  is,  the  rqfm-<x>  family  of  subroutines  will  be  used 
to  retrieve  <p>.  Its  lookup  method,  rqfm-lookups,  takes  as  its  argu¬ 
ment  a  proposition  of  the  form  (<r>  <xi  >  ...  <x,^  >  >). 

It  first  evaluates  the  term  (<r>  <xi  >  . . .  <Xn  >)  by  applying  LISP 
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•ubrcntme  correspoading  to  the  function  tymbol  <r>,  on  <r>i 
LISP  property,)  to  the  Ibt  <Xi  >  . . .  <x^  >.  ThU  return®  »  list  of  val- 
ues.  Rqfa-loo5cup«  then  uniSea  t%ch  of  these  with  >,  returning 

the  list  of  result!.  See  coiRputeble-repn,  rqfa-looJcup,  rqfa-lookup», 
relnproc,  reps. 

rqfa-looVoip  (rqfa-lookup  <p>) 

in  functlon4l]y  equivajeot  to  (six^larizo  (Rqfa-looicup*  p)).  See 
rqfa,  rqfa-lookupt* 

rqfa-lookup®  (rqf a** lookups  <p>) 

is  used  to  retrieve  the  propositions  <p>.  See  rqfa,  lisp. 

rrdisp  (rrdisp  <1>  <cl>  <•!>  <th>> 

performs  one  resolution  step  in  trying  to  derive  n  contradiction  from 
the  propositions  on  the  list  <1>.  The  list  <el>  contains  a  list  of  as¬ 
sumptions  made  in  preceding  steps.  The  binding  list  <al>  holds  the 
bindings  of  the  variables  from  preceding  steps.  The  theory  <tb>  holds 
the  conjunct!  from  the  negated  goal.  To  be  used,  all  prop<»itions  must 
be  in  conjunctive  form.  In  addition,  only  base->level  variables  are  treated 
as  variables,  any  meta-level  variables  are  treated  as  constants.  Given  a 
goal  list  (<p>  .  <!>},  rrdisp  generates  subgoals  by  negating  <p> 
to  get  <q>  and  looking  in  the  data  base  for  propositions  of  the  form 
<q>  or  (or  ...  <q>  ...).  It  also  uses  trueps  to  discover  whether  p 
is  assumable.  If  it  is  assumable  and  if  it  is  a  ground  proposition  after 
plugging  in  the  variable  bindings  returned  by  trueps,  brdisp  creates  a 
new  theory  that  includes  <th>,  asserts  the  proposition  b  that  theory, 
and  generates  appropriate  subgoals.  The  asse  ^ed  propositions  are  useful 
in  that  they  make  possible  consistency  checi.  g  before  making  assump¬ 
tions  in  subsequent  tUps.  The  order  in  which  multiple  rrdisp  tasks  are 
executed  can  be  influenced  via  appropriate  preferred  propositions.  See 
assunable,  enf . 

rsdisp  (rsdisp  <1>  <al>  <th>) 

performs  one  resolution  step  in  trying  to  derive  a  contradiction  from 
the  propositions  on  the  list  <1>.  The  binding  list  <al>  holds  the 
bindings  of  the  variables  from  preceding  steps.  The  theory  <th>  holds 
the  conjuncts  from  the  negated  goal.  To  be  used,  all  propositions  must 
be  in  conjunctive  form.  In  addition,  only  base-level  variables  are  treated 
as  variables,  any  meta-level  variable  is  treated  as  a  constant.  Given  a 
goal  list  (<p>  .  <1>),  rsdisp  generates  subgoals  by  negating  <p> 
to  get  <q>  and  looking  in  the  data  base  for  propositions  of  the  form 
<q>  or  (or  •••  <q>  •••)»  The  order  in  which  multiple  rsdisp  tasks 
are  executed  can  be  influenced  via  appropriate  prsfarrtd  propositions. 
See  cttf . 

runnable  (runnable  <k>) 

states  that  the  task  <k>  is  runnable.  A  runnable  task  is  applicable 
if  its  operator  is  a  Lisp  subroutine;  otherwise,  it  is  assumed  to  be  a  de¬ 
fined  task,  and  a  corresponding  invocation  of  exec  is  applicable.  In 


Appendix  C:  DictionMy  of  predicates  and  Sags  107 


MRS  demons  are  unpicmcnted  via  nmnabl#,  c.g.  to  tell  the  system  that 
it  should  print  a  g^eting  whenever  the  user  asserts  a  proposition  that 
someone  is  logged,  one  simply  asserts  (If  (Icggedla  $x)  (numablt 
(print  hello  t}))  and  (toaseert  (loggedln  kx)  fe).  See  appli* 
ieable,  scheduler. 

sanep  (santp  <x>  <y>) 

detennincs  whether  expressions  <x>  and  <j>  are  the  same  under  con¬ 
sistent  variable  renaming,  and  if  so  retnnu  a  binding  list  for  the  variables 
in  <x>.  For  example,  (p  (x  $y  lx)  is  the  same  as  (p  $y  $x  $y)  but 
not  (p  tx  ly  ly). 

scheduler  (scheduler) 

Scheduler  is  the  heart  of  the  MRS  system.  It  is  a  simple  deliberation- 
action  loop  that,  at  each  point  in  time,  decides  on  an  executable  task, 
executes  it,  and  repeats.  In  its  most  general  state,  the  choice  of  task 
is  made  by  calling  trtruep  to  find  a  task  <k>  such  that  (txseutable 
<k>)  is  true.  After  the  task  is  performed,  the  fact  it  recorded  by  call¬ 
ing  trasasrt  on  the  proposition  (executed  <k>}.  In  its  initial  state, 
MRS  contains  a  nnmber  of  propositions  to  help  scheduler  decide  on  an 
executable  task.  In  particular,  a  task  is  executable  if  it  is  applicable 
and  is  not  disqualified.  Once  a  task  becomes  applicable,  it  remains 
applicable  until  it  is  executed.  One  way  an  applicable  task  can  be  die* 
qualified  is  for  there  to  be  another  applicable  task  that  is  preferred 
to  it.  A  runnable  task  is  applicable  if  its  operator  is  a  Lisp  subroutine. 
Otherwise,  it  is  assumed  to  be  a  defined  task,  and  a  corresponding  exec 
task  is  applicable. 

This  full  generality  is  available  only  if  the  switches  executable  and  ex* 
ecuted  are  both  non-nil.  For  reasons  of  efficiency,  both  of  these  switches 
are  initially  set  to  nil,  and  an  optimised  version  of  this  loop  is  used  in¬ 
stead.  In  particular,  the  set  of  applicable  tasks  is  kept  as  the  value 
of  the  variable  agenda,  and  an  executable  task  is  obtained  fn>m  this 
list.  If  the  switch  preferred  is  nil,  the  first  element  of  the  list  is  taken; 
otherwise,  scheduler  uses  trtruep  to  compare  the  elements  using  the 
preferred  relation.  This  optimisation  is  fully  consistent  with  the  ax¬ 
ioms  described  above.  However,  it  is  recommended  that  the  user  not 
change  the  settings  of  executable  and  executed  without  careful  fore¬ 
thought.  Debugging  facilities  for  the  scheduler  architecture  are  not  very 
good  at  this  point.  However,  rudimentary  debugging  is  possible  using 
tracetask. 

aetdiff  (aetdiff  <x>  <y>  <b>) 

means  that  list  <b>  is  all  the  elements  in  list  <x>  that  are  not  in  list 
<y>. 

(setdiff  nil  $y  nil) 

(if  (and  (not  (element  $e  ty))  (setdiff  tl  ty  $e)) 

(setdiff  ($e  .  tl)  ty  (te  .  ts))) 

(if  (and  (element  te  ty)  (eetdiff  tl  ty  te)) 
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(setdiff  ($•  .  $1)  tf  $•)) 

Procedural  attachment:  truep-catdlf  f.  The  lisp  file  tet  must  be  loaded  from  the  mr*  directory. 

••tof  (setof  <x>  <p>  <•>) 

meant  that  <s>  it  the  tet  of  all  objeett  <x>  that  satisfy’  <p>. 

(if  (and  (bagof  $x  Ip  |b)  (•leatentsia  |b  la)) 

(setof  lx  Ip  la)) 

Procedural  attachments:  truep*aatof  and  loolrup-aatof •  The  Htp  file  set  mutt  be  loaded  from 

the  mrt  directory. 

ainglep  (ain^lep  <p>) 

retunu  t  when  the  proposition  <p>  hat  at  most  one  solution,  i.e.  when 
it  is  a  ground  proposition  or  an  atomic  proposition  with  a  functional 
operator  and  ground  arguments.  See  function. 

aingularize  (aingulariza  <x>) 

returns  the  singular-value  of  <x>.  That  is,  it  returns  (car  <x>).  See 
lookupbylookupa,  truepbytruepa. 

stash  (ataah  <p>) 

stores  the  proposition  <p>  in  the  data  base.  Stash  is  an  abstract  oper¬ 
ator  implemented  using  kb  and  toatash. 

ataah*and  (staah*and  (and  <Pi  >  •••  <Pn  >)) 

separately  stashes  each  of  the  conjuncts  <pi  >,. . <pn  >• 

staahapplicable  (stashapplicable  (applicable  <k>)) 

adds  <k>  to  agenda.  See  applicable. 

eubclaee  (eubclaes  <ci  >  <C3  >) 

means  that  the  set  <ca  >  is  a  subset  of  <ci  >  -  that  it,  all  members  of 
<ca  >  are  members  of  <Ci  >.  E.g.,  (eubclaee  nuaber  integer).  See 

claseee. 

subset  (subset  <x>  <y>) 

means  that  every  element  of  the  list  <x>  is  an  element  of  the  list  <y>. 

(subset  nil  ly) 

(if  (and  (element  It  ly)  (subset  $1  ly)) 

(subset  (|e  .  |1)  ly)) 

Procedural  attachment:  truep-subset.  The  lisp  file  set  must  be  loaded  horn  the  mrs  directory. 

succeed  (succeed  <z>) 

is  a  special  control  form.  Executing  this  form  causes  the  enclosing  doable 
task  to  succeed  or  the  enclosmg  undoable  task  to  fail.  In  addition,  aR 
other  subtasks  are  discarded. 

In  MRS  the  task  of  performing  an  operator  <op>  with  arguments 

<Xi  > .  <Xn  >  is  written  (<op>  <Xi  >  ...  <Xn  >.  The  oper^ 

ator  in  task  <k>  may  be  a  Lisp  subroutine,  an  MRS  subroutine  defined 
using  def ,  or  a  special  control  form  like  doand,  doable,  or  doall.  If 


task 
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tb 


template 


terse 


test 


thasaert 


theories 


theory 


thfalse 


threpn 


the  operator  b  a  Lbp  fubrontine,  the  task  must  have  have  an  additional 
argument  for  the  output  value,  and  it  will  succeed  only  if  the  last  ar¬ 
gument  uniBes  with  the  result  of  calling  the  subroutine  on  all  but  the 
last  argument.  For  example,  the  task  (edr  (a  b  c)  (hx  .  ty))  will 
succeed  with  the  variable  kx  bound  to  b  and  the  variable  ky  bound  to 
(c).  See  execute,  executes. 

(tb  <op>  <xl>...<xa>) 

makes  the  task  (<op>  <xl>  . . .  <xn>)  applicable  by  placbg  it  on  the 
agenda.  See  applicable,  agenda. 

(tesiplete  <x>  <t>) 

means  that  expression  <x>  should  be  output  as  <t>.  In  particular, 
if  an  expression  <y>  matches  <x>  with  bindbg  Ibt  <al>,  (output 
<x>)  returns  a  copy  of  <t>  in  which  each  variable  u  replaced  by  the 
result  of  calling  output  on  its  value  in  <al>.  Templates  are  used  by 
output. 

(domain  <x>  <i>  terns) 

means  that  the  <i>th  argument  to  the  subroutine  <x>  should  be  a 
term.  See  domain. 

(test  <flle>) 

runs  the  single  test  file  provided  <file>  and  prints  out  any  errors. 
Returns  the  number  of  errors  found  in  the  file. 

(tbassert  <p>  <th>) 

binds  theory  to  <th>  and  asserts  the  proposition  <p>.  See  assert, 
theory. 

(domain  <x>  <i>  theorise) 

means  that  the  <l>th  argument  to  the  subroutine  <x>  should  be  a 
theory.  See  domain. 

has  as  its  value  the  name  of  the  current  theory.  All  propositions  stored 
in  the  data  base  via  pr-stash  are  associated  with  the  theory  named 
as  the  value  of  theory  at  the  time  of  the  stash.  One  can  associate 
a  proposition  with  more  than  one  theory  by  repeating  the  call  to  pr- 
stash  with  different  values  for  theory.  Calling  pr-unetaeh  removes  a 
proposition  only  from  the  current  theory.  The  theory  named  as  the  value 
of  theory  is  always  active,  i.e.  the  propositions  associated  with  it  are 
available  for  retrieval  by  pr-lookup  and  pr-lookupe.  See  pr-staeh, 
pr-unetash,  pr*lookup,  and  pr-lookups. 

(thfalse  (unprovable  <p>)} 

calls  truep  on  the  proposition  <p>.  It  returns  nil  if  the  answer  is 
non-nil;  otherwise,  it  returns  truth. 

(threpn  <p>  <rpn>  <th>) 

means  that  the  representation  <rpn>  should  be  used  to  store  and  ac¬ 
cess  the  proposition  <p>  when  <tb>  is  an  active  theory.  The  effect 
of  having  conflicting  representations  for  a  proposition  stored  in  different 
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theoiies  is  undefined  when  both  theone*  are  active,  (See  rtpna  entry  for 
*iat  of  allowable  representations.)  See  activate,  deactivate,  theory, 
achieve,  repaa,  repn,  repa-aceert,  repn-method,  repa-unaeaert. 

thstash  (thatafih  <p>  <th>} 

binds  theory  to  <th>  and  stashes  the  propositioa  <p>.  See  ataah, 
theory. 

thtrue  (thtrue  (provable  <p>)) 

calls  truep  on  the  proposition  <p>  and  returns  the  answer. 

thunaasert  (thunasaart  <p>  <th>) 

binds  theory  to  <th>  and  unasserts  the  proposition  <p>.  See 
unaeeerti  theory. 

thunstaah  (thuaetaeh  <p>  <th>) 

binds  theory  to  <th>  and  unstashes  the  proposition  <p>.  See  unataah, 
theory. 

tl  (repn  <p>  tl) 

means  that  the  proposition  <p>  should  be  represented  in  the  tl  repre¬ 
sentation,  Le.  the  tl*<x>  family  of  subroutines  will  be  used  to  stash, 
unstash,  and  lookup  <p>.  This  representation  is  particularly  useful  for 
storing  propositions  involving  unary  relations,  e.g.  (fimction  f).  Note 
that  propositions  stored  in  this  way  are  not  associated  with  any  partic¬ 
ular  theory  and  cannot  be  found  by  PR-based  routines  like  prf  acts  or 
preontanta.  See  repn,  tl-lookup,  tl*atash,tl*un8taah 

tl-’lookup  (tl*lookup  (<r>  <a>) 

returns  truth  if  there  is  an  <r>  property  on  the  atom  <a>.  Both  <r> 
and  <a>  must  be  atoms.  See  tl. 

tl-atash  (tl*-8tash  (<r>  <a>)) 

sets  the  <r>  property  of  the  lisp  atom  <a>  to  t.  Both  <r>  and  <a> 
must  be  atoms.  See  tl. 

tl-unatash  (tl-unataah  (<r>  <a>}) 

removes  the  <r>  property  of  <a>.  Both  <r>  and  <a>  must  be  atoms. 
See  tl. 

(tB'-unaaaert  <p>) 

calls  unstash  on  <p>  and  then  calls  unassert  on  any  proposition  all  of 
whose  justifications  depend  on  <p>»  See  just. 

(to<g>  <p>  <f>) 

means  that  the  subroutine  <f  >  is  to  be  called  in  performing  the  action 
<g>  on  argument  <p>.  Each  of  MRSs  user-level  commands  has  associ¬ 
ated  with  it  a  relation  that  specifies  the  subroutine  to  be  used  in  carrying 
out  that  command.  The  relation  Is  named  by  prefixing  the  commands 
name  with  to,  e.g.  toAssert  from  assert.  See  kb. 

toachieve  (toachieve  <p>  <»>) 

means  that  the  method  <a>  should  be  used  to  perform  the  achieve  ac- 


tm^^unassert 


to<g> 


toatsert 


tocache 


tolookup 


tolockups 


toperceive 


toperceives 


toplevel 

tostash 


totruep 


totruepa 


tounachieve 
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tion  for  all  propositions  which  match  <p>.  See  kb,  achieve,  to<x>. 
(to&ssert  <p>  <a>) 

means  that  the  method  <a>  should  be  used  to  perform  the  assert 
action  for  all  propositions  which  match  <p>.  See  kb,  assert,  tc<x>. 

(tocache  <p>  <a>) 

means  that  the  method  <a>  should  be  used  to  cache  propositions  which 
match  <p>.  (This  <b>  will  only  be  used  when  the  variable  cache  has 
a  nonlllL  value.)  See  cache,  cachebystash,  to<x> 

(tolookup  <p>  <B>) 

means  that  the  method  <a>  should  be  used  to  determined  the  lookup 
value  for  aU  propositions  which  match  <p>.  See  kb,  lookup,  to<x>, 
tolookupe. 

(tolookupe  <p>  <B>) 

means  that  the  method  <a>  should  be  used  to  determined  the  lookups 
values  for  all  propositions  which  match  <p>.  See  kb,  lookups, 
to<x>,  tolookup. 

(toperceive  <p>  <a>) 

means  that  the  method  <b>  should  be  used  to  determined  the  per¬ 
ceive  value  for  all  propositions  which  match  <p>.  See  kb,  perceive, 
to<x>,  toperceives. 

(toperceives  <p>  <a>) 

means  that  the  method  <b>  should  be  used  to  determined  the  per¬ 
ceives  values  for  all  propositions  which  match  <p>.  See  kb,  per¬ 
ceives,  to<x>,  toperceive. 

(toplevel) 

is  a  read<>execute-print  loop.  See  execute. 

(toetash  <p>  <b>) 

means  that  the  method  <b>  should  be  used  to  perform  the  stash  action 
for  all  propositions  which  match  <p>.  See  kb,  stash,  to<x>. 

(totruep  <p>  <a>) 

means  that  the  method  <b>  should  be  used  to  determined  the  truep 
value  for  all  propositions  which  match  <p>.  See  kb,  truep,  to<x>, 
totrueps. 

(totrueps  <p>  <b>) 

means  that  the  method  <b>  should  be  used  to  determined  the  truep s 
values  for  all  propositions  which  match  <p>.  See  kb ,  trueps ,  to<x> , 
totruep. 

(tounachieve  <p>  <b>) 

means  that  the  method  <a>  should  be  used  to  perform  the  unachieve 
action  for  ail  propositions  which  match  <p>.  See  kb,  unachieve, 
to<x>. 
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tounassert 


tounstash 


tracetask 


traaaert 


trlookup 


trlookups 


trstash 


trtruep 


(toimaaaert  <p>  <a>) 

means  that  the  method  <a>  should  be  used  to  perform  the  unasaert  ac¬ 
tion  for  all  propositions  which  match  <p>.  See  kb,  unaosert,  to<x>. 

(tounsstaah  <p>  <a>) 

means  that  the  method  <m>  should  be  used  to  perform  the  unstash  ac¬ 
tion  for  all  propositions  which  match  <p>.  See  kb,  unstash,  to<x>. 

(tracetask  <p>) 

As  each  task  is  executed,  tasktrace  prints  out  the  name  of  the  subrou¬ 
tine  and  its  arguments  provided  they  match  <p>.  If  there  is  no  <p> 
argument  in  the  subroutine  call  then  a  list  of  all  tasks  which  are  to  be 
traced  is  printed.  See  imtracetask. 

(trassert  <p>} 

asserts  the  proposition  <p>  and  performs  forward  chainmg  as  appro¬ 
priate.  Trassert  is  MRSa  meta-level  assertion  routine  and  is  called  by 
many  MRS  subroutines.  The  default  is  simply  to  stash  a  proposition, 
but  there  arc  also  built-in  procedural  attachments  for  propositions  con¬ 
taining  certain  special  relations  (stored  on  each  relation  as  the  assert 
property).  A  frequently  used  procedural  attachment  is  the  depth- first 
forward  chaining  program  trf  c. 

(trlookup  <p>) 

locks  up  the  proposition  <p>.  If  successful,  it  returns  the  correspond¬ 
ing  binding  list;  otherwise,  it  returns  nil.  Trloookup  is  one  of  MRSs 
meta-level  lookup  routines  and  is  called  by  many  MRS  subroutines.  The 
default  procedure  uses  indexp  and  matchp  to  find  any  matching  propo¬ 
sitions  in  the  pr  representation,  but  there  are  also  built-in  procedural 
attachments  for  propositions  containing  many  common  relations  (stored 
on  each  relation  as  its  lookup  or  lookups  property). 

(trlookups  <p>) 

looks  up  the  proposition  <p>  and  returns  a  binding  list  for  each  match¬ 
ing  proposition  that  it  finds.  Trlookups  is  one  of  MRSs  meta-level 
lookup  routines  and  is  called  by  many  MRS  subroutines.  The  default 
procedure  uses  indexp  and  matchp  to  find  any  matching  propositions  in 
the  pr  representation,  but  there  are  also  built-in  procedural  attachments 
for  propositions  containing  many  common  relations  (stored  on  each  re¬ 
lation  as  its  lookup  lookups  property). 

(trstash  <p>) 

stashes  the  proposition  <p>.  Trstash  is  MRSs  meta-Ievel  stash  routine 
and  is  called  by  many  MRS  subroutines.  The  default  is  pr-stash,  but 
there  are  also  built-in  procedural  attachments  for  propositions  containing 
many  common  relations  (stored  on  each  relation  as  its  stash  property). 

(trtruep  <p>) 

tries  to  prove  the  proposition  <p>.  If  successful,  it  returns  a  corre¬ 
sponding  binding  Ibt;  otherwise,  it  returns  nil.  Trtruep  is  one  of  MRSs 
meta-level  theorem  proving  routines  and  is  called  by  many  MRS  subrou- 
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tines.  Only  meta-level  variables  arc  treated  as  variables  by  trtmep,  and 
all  base-level  variables  arc  treated  as  constants.  The  inference  procedure 
used  is  the  dcpth-flrst  backward  chaining  program  trbe,  but  there  are 
also  built-in  procedural  attachments  for  propositions  containing  many 
common  relations  (stored  on  each  relation  as  its  truep  or  trueps  prop- 
erty). 


trtrueps 

(trtrueps  <p>) 

tries  to  prove  the  proposition  <p>  and  returns  a  list  of  all  binding  lists 
for  which  it  is  successful.  Trtruepa  is  one  of  MRSs  meta^level  theorem 
proving  routines  and  is  called  by  many  MRS  subroutines.  Only  meta¬ 
level  variables  are  treated  as  variables  by  trtrueps,  and  all  base-level 
variables  are  treated  as  constants.  The  inference  procedure  used  is  the 
depth- first  backward  chaining  program  trbes,  but  there  are  also  built- 
in  procedural  attachments  for  propositions  containing  many  common 
relations  (stored  on  each  relation  as  its  truep  or  trueps  property). 

truep 

(truep  <p>) 

tries  to  prove  the  proposition  <p>.  If  it  is  successful,  it  returns  a  binding 
list  for  the  base-level  variables  in  <p>;  otherwise,  it  returns  nil.  Truep 
is  an  abstract  operator  implemented  using  kb  and  totruep. 

truep-bagof 

(truep-bagof  (bagof  <x>  <p>  <•>)) 

calls  trueps  on  <p>  and  matches  <s>  against  the  list  formed  by  plug¬ 
ging  the  answers  into  <x>. 

truep-is 

(truep-is  (is  <x>  <y>)) 

uses  getval  to  evaluate  the  arbitrarily  nested  expression  <x>  and  tries 
to  unify  the  answer  with  <y>.  See  is. 

truepbytrueps 

(truepbytrueps  <p>) 

is  equivalent  to  (singularize  (trueps  <p>)}. 

trueps 

(trueps  <p>) 

tries  to  prove  the  proposition  <p>  and  returns  a  list  of  all  binding  lists 
for  which  it  is  successful.  Trueps  is  an  abstract  operator  implemented 
using  kb  and  totrueps. 

truepsbytruep 

(truepsbytruep  <p>) 
is  equivalent  to  (pluralize  (truep  <p>)). 

trunassert 

(trunassert  <p>) 

unasserts  the  proposition  <p>.  Trunassert  is  MRSs  meta-level  unasser¬ 
tion  routine  and  is  called  by  many  MRS  subroutines.  The  default  is 
simply  to  unstash  a  proposition,  but  there  are  also  built-in  procedural 
attachments  for  propositions  containing  certain  special  relations  (stored 
on  each  relation  as  the  unassert  property). 

trunstash 

(trunstash  <p>) 

unstashes  the  proposition  <p>.  Trunstash  is  MRSs  meta-level  unstosh 
routine  and  b  called  by  many  MRS  subroutines.  The  default  is  pr¬ 
une  t  ash,  but  there  are  also  built-in  procedural  attachments  for  proposi- 
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truth 

tutor 

iinatsert 

U2ia8Bert*and 

unassert -iff 

undoable 


unifyp 


unincludes 


union 


tions  containing  many  common  relations  (stored  on  each  relation  as  its 
unstash  property). 

has  ((t  p  t))  as  its  value.  The  value  of  truth  occurs  as  the  last  pair 
in  binding  lists  returned  by  MRSs  retrieval  and  inference  procedures. 

(tutor) 

runs  an  interactive  tutor  that  introduces  one  to  the  basic  representation 
and  inference  mechanisms  of  MRS. 

(unassert  <p>) 

removes  the  proposition  <p>  from  the  data  base  and  performs  aU  appro¬ 
priate  inference.  Unassert  is  an  abstract  operator  implemented  using 
kb  and  tounassert. 

(unassert-and  (and  <pi  >  ...  <pn  >)) 
separately  unasserts  each  of  the  conjuncts  <pi  >»••.,  <Pn  >• 

(unassert-iff  (if  <p>  <q>)) 
asserts  (if  <p>  <q>)  and  (if  <q>  <p>). 

(undoable  <k>} 

designates  the  task  of  trying  to  execute  the  task  <k>.  The  task  (un¬ 
doable  <k>)  succeeds  only  if  there  is  no  successful  execution  of  <k>. 
Note  that  as  a  result  of  the  current  implementation,  it  is  not  possible  to 
interleave  sub  tasks  outside  a  doable  task  with  those  inside.  See  succeed 
and  cut. 

(unifyp  <x>  <y>) 

determines  whether  expressions  <x>  and  <y>  arc  unifiable,  and  if  so 
returns  their  most  general  uniher.  Unifyp  differs  from  matchp  in  that 
multiple  occurrences  of  the  same  variable  in  both  <x>  and  <y>  are  not 
treated  as  distinct  variables.  For  example,  (p  $x  b)  and  (p  a  $x)  are 
not  unifiable,  but  they  do  match. 

(unincludcs  <ti  >  <t2  >) 

removes  any  includes  link  between  theories  <ti  >  and  <t2  >.  See 
includes. 

(union  <x>  <y>  <b>) 

means  that  list  <b>  is  the  lists  <x>  and  <y>  appended  together. 


(union  nil  $y  $y) 

(if  (union  $1  $y  $s) 

(union  ($x  .  $1)  $y  ($x  .  $s))) 

Procedural  attachment:  truep-union.  The  lisp  file  set  must  be  loaded  from  the  mrs  directory. 

unknovm  (unknown  <p>) 

means  that  if  proposition  <p>  is  not  in  the  database  then  (unknown 
<p>}  is  true.  See  known. 

unprovable  (unprovable  <p>) 

means  that  proposition  (unprovable  <p>)  is  true  if  <p>  cannot  be 


unstc  jil 

unatash-and 

imatashapplicabla 

untracetask 

valua 

variable 

varp 

where 

why 
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proved  uilng  the  normal  mfchanLsm*  for  proving  <p>.  See  provable, 
(unstaeh  <p>) 

removes  the  proposition  <p>  from  the  data  bare.  Note  this  is  not  equiv- 
alcnt  to  asserting  the  negation  of  <p>.  Unstaah  is  an  abstract  operator 
implemented  using  kb  and  toi^v  i-.ash. 

(unstash^and  (and  <pi  >  ...  >)) 

separately  unstasbes  each  of  it  ?  conjunct!  <pi  <Pn  >* 

(unstashapplicsbla  (applicable  <k>)) 
removes  <k>  from  agenda.  See  appl  1  cable. 

(imtracetask  <p>) 

untraces  the  task  <p>.  If  there  is  no  <p>  argument  iu  the  tubrou* 
tine  call  then  it  untraccs  rll  <p>  that  are  currently  being  traced.  See 
tracetask. 

(value  <x>  <y>) 

means  that  the  atom  <x>  has  value  <y>. 

(variable  <x>) 

means  that  the  symbol  <x>  is  a  variable. 

(varp  <xp>) 

returns  a  non-nil  value  if  <xp>  is  a  variable  and  otherwise  returns  nil. 
See  blvarp  and  alvarp. 

(where  <p>) 

prints  out  a  message  for  each  recorded  justification  in  which  <p>  is  a 
premise.  The  message  includes  information  about  the  justified  proposi* 
tion,  the  inference  method,  and  all  premises.  See  Justify,  just. 

(why  <p>) 

prints  out  a  message  for  each  recorded  justification  for  the  proposition 
<p>.  The  message  includes  information  about  the  relevant  inference 
method  and  all  premises.  See  justify,  just. 
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